taskManeage - 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
Assigned to:  None Percent Complete:  0%
Open/Closed:  Open Effort:  0.00

Tue 23 Jun 2020 05:28:39 PM UTC, comment #2: 

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.


Boud Roukema <boud>
Group Member
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>
Group administrator
Tue 23 Jun 2020 02:44:57 PM UTC, original submission:  

It appears that a shell satisfying POSIX.1-2017 standards must correctly process

${expression}

and

${parameter}


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:
https://stackoverflow.com/questions/8748831/when-do-we-need-curly-braces-around-shell-variables#8748880

There are also recommendations to use double quotes:
https://unix.stackexchange.com/questions/4899/var-vs-var-and-to-quote-or-not-to-quote

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>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by makhlaghi (Posted a comment)
  • -email is unavailable- added by boud (Submitted the item)
  •  

    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 SummaryWhy not use curly brackets for generic shell or bash variables? Defining coding conventions

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code