Maneage - Tasks: task #15706, Defining coding conventions
You are not allowed to post comments on this tracker with your current authentication level.
task #15706: Defining coding conventions
Submitter: | Boud Roukema <boud> | ||
Submitted: | Tue 23 Jun 2020 02:44:57 PM UTC | ||
Should Start On: | Tue 23 Jun 2020 12:00:00 AM UTC | Should be Finished on: | Tue 23 Jun 2020 12:00:00 AM UTC |
Category: | None | Priority: | 5 - Normal |
Status: | None | Privacy: | Public |
Percent Complete: | 0% | Assigned to: | None |
Open/Closed: | Open | Effort: | 0.00 |
Tue 23 Jun 2020 05:28:39 PM UTC, comment #2: |
Boud Roukema <boud>![]() |
Tue 23 Jun 2020 03:43:23 PM UTC, comment #1: This is a very good point, and following the discussion in task #15701, I think it is appropriate to change the title of this task to "Defining coding conventions".
Besides being practical and helping the core Maneage branch be more unified, having a "Coding Convention" section in 'README-hacking.md' can have great educational value for a scientist who is not too familiar with writing code, thus helping them alot. We can discuss the various conventions and what to apply in this task.
Regarding the POSIX.1-2017 standard, as the year suggests it is relatively recent and not fully reliable on older shells. Even today (the year 2020), I have seen some people with shells that were written in 2006! I think probably using double quotations is a more portable solution when we are relying on the host's shell. But I don't have any special preference, the main point is portability and where this convention would apply.
Generally, in Maneage we have three layers of Shell:
1) The host's shell. This is used to run the 'project' and 'reproduce/software/shell/configure.sh' scripts. We have to be the most portable here and try our best to make no assumptions beyond a modern POSIX standard (Maybe POSIX.1-2001? see the POSIX version history).
2) A fixed version of modern Dash (the Debian minimalist POSIX-compatible shell). This is used for building basic software (including a fixed version of GNU Bash) in 'reproduce/software/make/basic.mk'.
3) A fixed version of modern GNU Bash. This is used in building high-level software and the analysis phase.
In the last two, we should be able to assume modern POSIX shell features. |
Mohammad Akhlaghi <makhlaghi>![]() |
Tue 23 Jun 2020 02:44:57 PM UTC, original submission:
It appears that a shell satisfying POSIX.1-2017 standards must correctly process
and
See https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_02
It seems to be a general recommendation to write ${parameter} rather than $parameter:
There are also recommendations to use double quotes:
Do we have any good reasons not to use {} around parameter names in either (i) the generic POSIX shell or (ii) the GNU bash shell?
|
Boud Roukema <boud>![]() |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follows 1 latest change.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2020-06-23 | makhlaghi | Summary | Why not use curly brackets for generic shell or bash variables? | ![]() |
Defining coding conventions |
I didn't realise point 2) - that we use Dash in the basic.mk step. I may have noticed it and forgot.
The wider task name makes sense.
I agree on the question of portability, but we also want long-term reproducibility, and we don't want to sacrifice security. :)
With the anecdote: do you mean people using a shell (binary) that was written in 2006? or that the shell script was written in 2006?
I think that we should only require compatibility with an open-access standard. https://en.wikipedia.org/wiki/POSIX#Versions
"This document set for the Single UNIX Specification, Version 3 (UNIX 03). The PDF documents are only available to employees of members of The Open Group."
Section 2.6.2 of POSIX.1-2008 - https://pubs.opengroup.org/onlinepubs/9699919799.2008edition/ - seems to give the equivalent of POSIX-1.2017 - for requiring ${parameter} to be recognised.
These pages seem to be well-archived: https://web.archive.org/web/20200516232627/https://pubs.opengroup.org/onlinepubs/009695399/ lists 459 snapshots for the top page.
How about 1) IEEE Std 1003.1-2004; 2)+3) POSIX.1-2017 ?
I don't know if there exists an informal name POSIX.1-2004 for IEEE Std 1003.1-2004.