Bug#864615: please update version of posix standard for scripts (section 10.4)

[Gunnar Wolf]

Sean Whitton dijo [Fri, Jun 15, 2018 at 01:06:43PM +0100]:
> Thank you for this.
> 
> Let's use POSIX.1-2017 rather than relying on the download filenames.
> 
> Please find a revised patch below; hopefully Gunnar will renew his
> second, and perhaps you'll second too, Simon.  Again, all that the patch
> does is:

Sorry for the delay!

Of course, I second the following text.

> - replace the string "SUSv3" with "POSIX.1-2017" wherever it appears
> - update the footnote which gives the download URI for the standard
> 
> > or perhaps replacing SUSv3 with POSIX and clarifying that we use POSIX
> > to refer to the latest version of the POSIX.1 standard.
> 
> This is an interesting suggestion.  So far as I can see the only
> advantage to this is that we don't need Policy bugs to bump the version
> of the standard we target.  That does not strike me as a large enough
> advantage to justify giving up explicit control over the version of the
> standard that applies to Debian -- do you see other advantages?
> 
> Patch:
> 
> > diff --git a/policy/ch-files.rst b/policy/ch-files.rst
> > index 90ae58a..f31a3b4 100644
> > --- a/policy/ch-files.rst
> > +++ b/policy/ch-files.rst
> > @@ -203,9 +203,9 @@ may instead be easier to check the exit status of 
> > commands directly. See
> >  Every script should use ``set -e`` or check the exit status of *every*
> >  command.
> >  
> > -Scripts may assume that ``/bin/sh`` implements the SUSv3 Shell Command
> > +Scripts may assume that ``/bin/sh`` implements the POSIX.1-2017 Shell 
> > Command
> >  Language  [#]_ plus the following additional features not mandated by
> > -SUSv3.. [#]_
> > +POSIX.1-2017.. [#]_
> >  
> >  -  ``echo -n``, if implemented as a shell built-in, must not generate a
> > newline.
> > @@ -238,13 +238,13 @@ SUSv3.. [#]_
> > which are the same as for ``kill`` above, 13 (SIGPIPE) must be
> > allowed.
> >  
> > -If a shell script requires non-SUSv3 features from the shell interpreter
> > +If a shell script requires non-POSIX.1-2017 features from the shell 
> > interpreter
> >  other than those listed above, the appropriate shell must be specified
> >  in the first line of the script (e.g., ``#!/bin/bash``) and the package
> >  must depend on the package providing the shell (unless the shell package
> >  is marked "Essential", as in the case of ``bash``).
> >  
> > -You may wish to restrict your script to SUSv3 features plus the above
> > +You may wish to restrict your script to POSIX.1-2017 features plus the 
> > above
> >  set when possible so that it may use ``/bin/sh`` as its interpreter.
> >  Checking your script with ``checkbashisms`` from the devscripts package
> >  or running your script with an alternate shell such as ``posh`` may help
> > @@ -762,10 +762,10 @@ restricted to ASCII when it is possible to do so.
> > complicated and difficult to manage.
> >  
> >  .. [#]
> > -   Single UNIX Specification, version 3, which is also IEEE 1003.1-2004
> > -   (POSIX), and is available on the World Wide Web from `The Open
> > -   Group `_ after free
> > -   registration.
> > +   The Open Group Base Specifications Issue 7, 2018 Edition, which is
> > +   also known as POSIX.1-2017 and as IEEE Std 1003.1-2017 and is
> > +   available on the World Wide Web from `The Open Group
> > +   `_.
> >  
> >  .. [#]
> > These features are in widespread use in the Linux community and are
> > diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst
> > index 7d85c00..32619e8 100644
> > --- a/policy/ch-opersys.rst
> > +++ b/policy/ch-opersys.rst
> > @@ -479,7 +479,7 @@ configurable values should not be placed directly in 
> > the script.
> >  Instead, they should be placed in a file in ``/etc/default``, which
> >  typically will have the same base name as the ``init.d`` script. This
> >  extra file should be sourced by the script when the script runs. It must
> > -contain only variable settings and comments in SUSv3 ``sh`` format. It
> > +contain only variable settings and comments in POSIX.1-2017 ``sh`` format. 
> > It
> >  may either be a ``conffile`` or a configuration file maintained by the
> >  package maintainer scripts. See :ref:`s-config-files` for
> >  more details.


signature.asc
Description: PGP signature

Bug#864615: please update version of posix standard for scripts (section 10.4)

[Julien Cristau]

On 06/15/2018 02:06 PM, Sean Whitton wrote:
> Patch:
> 
>> diff --git a/policy/ch-files.rst b/policy/ch-files.rst
>> index 90ae58a..f31a3b4 100644
>> --- a/policy/ch-files.rst
>> +++ b/policy/ch-files.rst
>> @@ -203,9 +203,9 @@ may instead be easier to check the exit status of 
>> commands directly. See
>>  Every script should use ``set -e`` or check the exit status of *every*
>>  command.
>>  
>> -Scripts may assume that ``/bin/sh`` implements the SUSv3 Shell Command
>> +Scripts may assume that ``/bin/sh`` implements the POSIX.1-2017 Shell 
>> Command
>>  Language  [#]_ plus the following additional features not mandated by
>> -SUSv3.. [#]_
>> +POSIX.1-2017.. [#]_
>>  
>>  -  ``echo -n``, if implemented as a shell built-in, must not generate a
>> newline.
>> @@ -238,13 +238,13 @@ SUSv3.. [#]_
>> which are the same as for ``kill`` above, 13 (SIGPIPE) must be
>> allowed.
>>  
>> -If a shell script requires non-SUSv3 features from the shell interpreter
>> +If a shell script requires non-POSIX.1-2017 features from the shell 
>> interpreter
>>  other than those listed above, the appropriate shell must be specified
>>  in the first line of the script (e.g., ``#!/bin/bash``) and the package
>>  must depend on the package providing the shell (unless the shell package
>>  is marked "Essential", as in the case of ``bash``).
>>  
>> -You may wish to restrict your script to SUSv3 features plus the above
>> +You may wish to restrict your script to POSIX.1-2017 features plus the above
>>  set when possible so that it may use ``/bin/sh`` as its interpreter.
>>  Checking your script with ``checkbashisms`` from the devscripts package
>>  or running your script with an alternate shell such as ``posh`` may help
>> @@ -762,10 +762,10 @@ restricted to ASCII when it is possible to do so.
>> complicated and difficult to manage.
>>  
>>  .. [#]
>> -   Single UNIX Specification, version 3, which is also IEEE 1003.1-2004
>> -   (POSIX), and is available on the World Wide Web from `The Open
>> -   Group `_ after free
>> -   registration.
>> +   The Open Group Base Specifications Issue 7, 2018 Edition, which is
>> +   also known as POSIX.1-2017 and as IEEE Std 1003.1-2017 and is
>> +   available on the World Wide Web from `The Open Group
>> +   `_.
>>  
>>  .. [#]
>> These features are in widespread use in the Linux community and are
>> diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst
>> index 7d85c00..32619e8 100644
>> --- a/policy/ch-opersys.rst
>> +++ b/policy/ch-opersys.rst
>> @@ -479,7 +479,7 @@ configurable values should not be placed directly in the 
>> script.
>>  Instead, they should be placed in a file in ``/etc/default``, which
>>  typically will have the same base name as the ``init.d`` script. This
>>  extra file should be sourced by the script when the script runs. It must
>> -contain only variable settings and comments in SUSv3 ``sh`` format. It
>> +contain only variable settings and comments in POSIX.1-2017 ``sh`` format. 
>> It
>>  may either be a ``conffile`` or a configuration file maintained by the
>>  package maintainer scripts. See :ref:`s-config-files` for
>>  more details.
> 
Seconded.

Thanks,
Julien

Bug#864615: please update version of posix standard for scripts (section 10.4)

[Simon McVittie]

On Fri, 15 Jun 2018 at 13:06:43 +0100, Sean Whitton wrote:
> On Thu, Jun 14 2018, Simon McVittie wrote:
> > I'd suggest replacing SUSv3 with POSIX.1-2017 or SUSv4 2018 edition
> > instead,
> 
> Please find a revised patch below; hopefully Gunnar will renew his
> second, and perhaps you'll second too, Simon.

Seconded (full text of what I'm seconding below).

> > or perhaps replacing SUSv3 with POSIX and clarifying that we use POSIX
> > to refer to the latest version of the POSIX.1 standard.
> 
> This is an interesting suggestion.  So far as I can see the only
> advantage to this is that we don't need Policy bugs to bump the version
> of the standard we target.  That does not strike me as a large enough
> advantage to justify giving up explicit control over the version of the
> standard that applies to Debian -- do you see other advantages?

(Note that I have seconded the version that says POSIX.1-2017; I don't
want the perfect to be the enemy of the good here.)

Having explicit control over the version of the standard we target
doesn't seem to have brought us any particular benefits, and it has
taken us 9½ years (SUSv4 was published in December 2008) to update
Policy from SUSv3 to SUSv4. I would hope that the upstream and Debian
maintainers of the shells and command-line utilities that we ship already
consider unexplained divergence from POSIX to be a (possibly minor) bug,
and they are almost certainly thinking of the latest version of POSIX
rather than the semi-arbitrary version mentioned in Debian Policy :-)

(I say "unexplained divergence" because some GNU stuff is deliberately
non-POSIX, in areas where its maintainers can justify that decision.)

I find it difficult to imagine a future in which the maintainers of POSIX
make changes that Debian doesn't want to follow, and in such a future
we would have the escape route of either writing exceptions into Policy,
or ceasing to track new POSIX versions at that time and "freezing" at
the last "good" version of POSIX, analogous to what we'd do if the
maintainers of an important upstream package like Linux or glibc went
in directions we strongly objected to.

But perhaps explicit is better than implicit, and hopefully next time
we have a change like this it'll take significantly less than a decade.
If people like my proposed patches for FHS 3.0 (#787816) it might take
a mere 3 years to adopt FHS 3.0...

> Patch:
> 
> > diff --git a/policy/ch-files.rst b/policy/ch-files.rst
> > index 90ae58a..f31a3b4 100644
> > --- a/policy/ch-files.rst
> > +++ b/policy/ch-files.rst
> > @@ -203,9 +203,9 @@ may instead be easier to check the exit status of 
> > commands directly. See
> >  Every script should use ``set -e`` or check the exit status of *every*
> >  command.
> >  
> > -Scripts may assume that ``/bin/sh`` implements the SUSv3 Shell Command
> > +Scripts may assume that ``/bin/sh`` implements the POSIX.1-2017 Shell 
> > Command
> >  Language  [#]_ plus the following additional features not mandated by
> > -SUSv3.. [#]_
> > +POSIX.1-2017.. [#]_
> >  
> >  -  ``echo -n``, if implemented as a shell built-in, must not generate a
> > newline.
> > @@ -238,13 +238,13 @@ SUSv3.. [#]_
> > which are the same as for ``kill`` above, 13 (SIGPIPE) must be
> > allowed.
> >  
> > -If a shell script requires non-SUSv3 features from the shell interpreter
> > +If a shell script requires non-POSIX.1-2017 features from the shell 
> > interpreter
> >  other than those listed above, the appropriate shell must be specified
> >  in the first line of the script (e.g., ``#!/bin/bash``) and the package
> >  must depend on the package providing the shell (unless the shell package
> >  is marked "Essential", as in the case of ``bash``).
> >  
> > -You may wish to restrict your script to SUSv3 features plus the above
> > +You may wish to restrict your script to POSIX.1-2017 features plus the 
> > above
> >  set when possible so that it may use ``/bin/sh`` as its interpreter.
> >  Checking your script with ``checkbashisms`` from the devscripts package
> >  or running your script with an alternate shell such as ``posh`` may help
> > @@ -762,10 +762,10 @@ restricted to ASCII when it is possible to do so.
> > complicated and difficult to manage.
> >  
> >  .. [#]
> > -   Single UNIX Specification, version 3, which is also IEEE 1003.1-2004
> > -   (POSIX), and is available on the World Wide Web from `The Open
> > -   Group `_ after free
> > -   registration.
> > +   The Open Group Base Specifications Issue 7, 2018 Edition, which is
> > +   also known as POSIX.1-2017 and as IEEE Std 1003.1-2017 and is
> > +   available on the World Wide Web from `The Open Group
> > +   `_.
> >  
> >  .. [#]
> > These features are in widespread use in the Linux community and are
> > diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst
> > index 7d85c00..32619e8 100644
> > --- 

Bug#864615: please update version of posix standard for scripts (section 10.4)

[Sean Whitton]

Hello Simon,

On Thu, Jun 14 2018, Simon McVittie wrote:

> http://pubs.opengroup.org/onlinepubs/9699919799/ has now been replaced
> (see #900882, for which I'm preparing a patch) with POSIX.1-2017, which
> is variously labelled as:
>
> * POSIX.1-2017
> * IEEE Std 1003.1-2017
> * The Open Group Technical Standard Base Specifications, Issue 7
> * The Open Group Base Specifications Issue 7, 2018 Edition
>
> and no longer has visible "Single Unix Specification" branding at all.
> However, the downloadable tarballs at
> http://pubs.opengroup.org/onlinepubs/9699919799/download/
> have basename susv4-2018. According to Wikipedia it "incorporates Singles
> UNIX Specification TC1 and TC2, and is technically identical to the
> 2016 edition."
>
> I'd suggest replacing SUSv3 with POSIX.1-2017 or SUSv4 2018 edition
> instead,

Thank you for this.

Let's use POSIX.1-2017 rather than relying on the download filenames.

Please find a revised patch below; hopefully Gunnar will renew his
second, and perhaps you'll second too, Simon.  Again, all that the patch
does is:

- replace the string "SUSv3" with "POSIX.1-2017" wherever it appears
- update the footnote which gives the download URI for the standard

> or perhaps replacing SUSv3 with POSIX and clarifying that we use POSIX
> to refer to the latest version of the POSIX.1 standard.

This is an interesting suggestion.  So far as I can see the only
advantage to this is that we don't need Policy bugs to bump the version
of the standard we target.  That does not strike me as a large enough
advantage to justify giving up explicit control over the version of the
standard that applies to Debian -- do you see other advantages?

Patch:

> diff --git a/policy/ch-files.rst b/policy/ch-files.rst
> index 90ae58a..f31a3b4 100644
> --- a/policy/ch-files.rst
> +++ b/policy/ch-files.rst
> @@ -203,9 +203,9 @@ may instead be easier to check the exit status of 
> commands directly. See
>  Every script should use ``set -e`` or check the exit status of *every*
>  command.
>  
> -Scripts may assume that ``/bin/sh`` implements the SUSv3 Shell Command
> +Scripts may assume that ``/bin/sh`` implements the POSIX.1-2017 Shell Command
>  Language  [#]_ plus the following additional features not mandated by
> -SUSv3.. [#]_
> +POSIX.1-2017.. [#]_
>  
>  -  ``echo -n``, if implemented as a shell built-in, must not generate a
> newline.
> @@ -238,13 +238,13 @@ SUSv3.. [#]_
> which are the same as for ``kill`` above, 13 (SIGPIPE) must be
> allowed.
>  
> -If a shell script requires non-SUSv3 features from the shell interpreter
> +If a shell script requires non-POSIX.1-2017 features from the shell 
> interpreter
>  other than those listed above, the appropriate shell must be specified
>  in the first line of the script (e.g., ``#!/bin/bash``) and the package
>  must depend on the package providing the shell (unless the shell package
>  is marked "Essential", as in the case of ``bash``).
>  
> -You may wish to restrict your script to SUSv3 features plus the above
> +You may wish to restrict your script to POSIX.1-2017 features plus the above
>  set when possible so that it may use ``/bin/sh`` as its interpreter.
>  Checking your script with ``checkbashisms`` from the devscripts package
>  or running your script with an alternate shell such as ``posh`` may help
> @@ -762,10 +762,10 @@ restricted to ASCII when it is possible to do so.
> complicated and difficult to manage.
>  
>  .. [#]
> -   Single UNIX Specification, version 3, which is also IEEE 1003.1-2004
> -   (POSIX), and is available on the World Wide Web from `The Open
> -   Group `_ after free
> -   registration.
> +   The Open Group Base Specifications Issue 7, 2018 Edition, which is
> +   also known as POSIX.1-2017 and as IEEE Std 1003.1-2017 and is
> +   available on the World Wide Web from `The Open Group
> +   `_.
>  
>  .. [#]
> These features are in widespread use in the Linux community and are
> diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst
> index 7d85c00..32619e8 100644
> --- a/policy/ch-opersys.rst
> +++ b/policy/ch-opersys.rst
> @@ -479,7 +479,7 @@ configurable values should not be placed directly in the 
> script.
>  Instead, they should be placed in a file in ``/etc/default``, which
>  typically will have the same base name as the ``init.d`` script. This
>  extra file should be sourced by the script when the script runs. It must
> -contain only variable settings and comments in SUSv3 ``sh`` format. It
> +contain only variable settings and comments in POSIX.1-2017 ``sh`` format. It
>  may either be a ``conffile`` or a configuration file maintained by the
>  package maintainer scripts. See :ref:`s-config-files` for
>  more details.

-- 
Sean Whitton

Bug#864615: please update version of posix standard for scripts (section 10.4)

[Simon McVittie]

On Sat, 14 Oct 2017 at 15:28:04 -0700, Sean Whitton wrote:
> On Sat, Oct 14 2017, Adam D. Barratt wrote:
> > The 2016 edition is Technical Corrigendum 2. I'm not sure that it's
> > conventional to use versioning such as 4.2 in such cases, however. I'd
> > expect it to be referred to as SUSv4, SUSv4TC2, or SUSv4 2016 edition;
> > the latter seems to be more common.

http://pubs.opengroup.org/onlinepubs/9699919799/ has now been replaced
(see #900882, for which I'm preparing a patch) with POSIX.1-2017, which
is variously labelled as:

* POSIX.1-2017
* IEEE Std 1003.1-2017
* The Open Group Technical Standard Base Specifications, Issue 7
* The Open Group Base Specifications Issue 7, 2018 Edition

and no longer has visible "Single Unix Specification" branding at all.
However, the downloadable tarballs at
http://pubs.opengroup.org/onlinepubs/9699919799/download/
have basename susv4-2018. According to Wikipedia it "incorporates Singles
UNIX Specification TC1 and TC2, and is technically identical to the
2016 edition."

I'd suggest replacing SUSv3 with POSIX.1-2017 or SUSv4 2018 edition
instead, or perhaps replacing SUSv3 with POSIX and clarifying that we
use POSIX to refer to the latest version of the POSIX.1 standard.

smcv

Bug#864615: please update version of posix standard for scripts (section 10.4)

[Gunnar Wolf]

Sean Whitton dijo [Sat, Oct 14, 2017 at 03:28:04PM -0700]:
> > The 2016 edition is Technical Corrigendum 2. I'm not sure that it's
> > conventional to use versioning such as 4.2 in such cases, however. I'd
> > expect it to be referred to as SUSv4, SUSv4TC2, or SUSv4 2016 edition;
> > the latter seems to be more common.
> 
> Thank you for the clarification, Adam.
> 
> I am seeking seconds for the following patch.  It's not so readable, so
> let me summarise the changes:
> 
> - replace the string "SUSv3" with "SUSv4 (2016 edition)" wherever it
>   appears
> - reflow paragraphs where necessary

I second your patch; it makes sense to do this simple update. Quoting
it in full just to make _what_ I'm seconding explicit.

> For the reasons explained in my previous e-mail, I think it's reasonable
> to make this change now.
> 
> > diff --git a/policy/ch-files.rst b/policy/ch-files.rst
> > index d4df316..dc0d152 100644
> > --- a/policy/ch-files.rst
> > +++ b/policy/ch-files.rst
> > @@ -202,9 +202,9 @@ may instead be easier to check the exit status of 
> > commands directly. See
> >  Every script should use ``set -e`` or check the exit status of *every*
> >  command.
> >
> > -Scripts may assume that ``/bin/sh`` implements the SUSv3 Shell Command
> > -Language  [#]_ plus the following additional features not mandated by
> > -SUSv3.. [#]_
> > +Scripts may assume that ``/bin/sh`` implements the SUSv4 (2016
> > +edition) Shell Command Language [#]_ plus the following additional
> > +features not mandated by SUSv4 (2016 edition).. [#]_
> >
> >  -  ``echo -n``, if implemented as a shell built-in, must not generate a
> > newline.
> > @@ -237,18 +237,20 @@ SUSv3.. [#]_
> > which are the same as for ``kill`` above, 13 (SIGPIPE) must be
> > allowed.
> >
> > -If a shell script requires non-SUSv3 features from the shell interpreter
> > -other than those listed above, the appropriate shell must be specified
> > -in the first line of the script (e.g., ``#!/bin/bash``) and the package
> > -must depend on the package providing the shell (unless the shell package
> > -is marked "Essential", as in the case of ``bash``).
> > -
> > -You may wish to restrict your script to SUSv3 features plus the above
> > -set when possible so that it may use ``/bin/sh`` as its interpreter.
> > -Checking your script with ``checkbashisms`` from the devscripts package
> > -or running your script with an alternate shell such as ``posh`` may help
> > -uncover violations of the above requirements. If in doubt whether a
> > -script complies with these requirements, use ``/bin/bash``.
> > +If a shell script requires non-SUSv4 (2016 edition) features from the
> > +shell interpreter other than those listed above, the appropriate shell
> > +must be specified in the first line of the script (e.g.,
> > +``#!/bin/bash``) and the package must depend on the package providing
> > +the shell (unless the shell package is marked "Essential", as in the
> > +case of ``bash``).
> > +
> > +You may wish to restrict your script to SUSv4 (2016 edition) features
> > +plus the above set when possible so that it may use ``/bin/sh`` as its
> > +interpreter.  Checking your script with ``checkbashisms`` from the
> > +devscripts package or running your script with an alternate shell such
> > +as ``posh`` may help uncover violations of the above requirements. If
> > +in doubt whether a script complies with these requirements, use
> > +``/bin/bash``.
> >
> >  Perl scripts should check for errors when making any system calls,
> >  including ``open``, ``print``, ``close``, ``rename`` and ``system``.
> > diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst
> > index 7d9e20a..9574f82 100644
> > --- a/policy/ch-opersys.rst
> > +++ b/policy/ch-opersys.rst
> > @@ -461,19 +461,19 @@ statement at the top of the script, like this:
> >  test -f program-executed-later-in-script || exit 0
> >
> >  Often there are some variables in the ``init.d`` scripts whose values
> > -control the behavior of the scripts, and which a system administrator is
> > -likely to want to change. As the scripts themselves are frequently
> > -``conffile``\ s, modifying them requires that the administrator merge in
> > -their changes each time the package is upgraded and the ``conffile``
> > -changes. To ease the burden on the system administrator, such
> > -configurable values should not be placed directly in the script.
> > +control the behavior of the scripts, and which a system administrator
> > +is likely to want to change. As the scripts themselves are frequently
> > +``conffile``\ s, modifying them requires that the administrator merge
> > +in their changes each time the package is upgraded and the
> > +``conffile`` changes. To ease the burden on the system administrator,
> > +such configurable values should not be placed directly in the script.
> >  Instead, they should be placed in a file in ``/etc/default``, which
> >  typically will have the same base name as the ``init.d`` script. This
> > 

Bug#864615: please update version of posix standard for scripts (section 10.4)

[Sean Whitton]

control: tag -1 -moreinfo +patch

Hello,

On Sat, Oct 14 2017, Adam D. Barratt wrote:

> The 2016 edition is Technical Corrigendum 2. I'm not sure that it's
> conventional to use versioning such as 4.2 in such cases, however. I'd
> expect it to be referred to as SUSv4, SUSv4TC2, or SUSv4 2016 edition;
> the latter seems to be more common.

Thank you for the clarification, Adam.

I am seeking seconds for the following patch.  It's not so readable, so
let me summarise the changes:

- replace the string "SUSv3" with "SUSv4 (2016 edition)" wherever it
  appears
- reflow paragraphs where necessary

For the reasons explained in my previous e-mail, I think it's reasonable
to make this change now.

> diff --git a/policy/ch-files.rst b/policy/ch-files.rst
> index d4df316..dc0d152 100644
> --- a/policy/ch-files.rst
> +++ b/policy/ch-files.rst
> @@ -202,9 +202,9 @@ may instead be easier to check the exit status of 
> commands directly. See
>  Every script should use ``set -e`` or check the exit status of *every*
>  command.
>
> -Scripts may assume that ``/bin/sh`` implements the SUSv3 Shell Command
> -Language  [#]_ plus the following additional features not mandated by
> -SUSv3.. [#]_
> +Scripts may assume that ``/bin/sh`` implements the SUSv4 (2016
> +edition) Shell Command Language [#]_ plus the following additional
> +features not mandated by SUSv4 (2016 edition).. [#]_
>
>  -  ``echo -n``, if implemented as a shell built-in, must not generate a
> newline.
> @@ -237,18 +237,20 @@ SUSv3.. [#]_
> which are the same as for ``kill`` above, 13 (SIGPIPE) must be
> allowed.
>
> -If a shell script requires non-SUSv3 features from the shell interpreter
> -other than those listed above, the appropriate shell must be specified
> -in the first line of the script (e.g., ``#!/bin/bash``) and the package
> -must depend on the package providing the shell (unless the shell package
> -is marked "Essential", as in the case of ``bash``).
> -
> -You may wish to restrict your script to SUSv3 features plus the above
> -set when possible so that it may use ``/bin/sh`` as its interpreter.
> -Checking your script with ``checkbashisms`` from the devscripts package
> -or running your script with an alternate shell such as ``posh`` may help
> -uncover violations of the above requirements. If in doubt whether a
> -script complies with these requirements, use ``/bin/bash``.
> +If a shell script requires non-SUSv4 (2016 edition) features from the
> +shell interpreter other than those listed above, the appropriate shell
> +must be specified in the first line of the script (e.g.,
> +``#!/bin/bash``) and the package must depend on the package providing
> +the shell (unless the shell package is marked "Essential", as in the
> +case of ``bash``).
> +
> +You may wish to restrict your script to SUSv4 (2016 edition) features
> +plus the above set when possible so that it may use ``/bin/sh`` as its
> +interpreter.  Checking your script with ``checkbashisms`` from the
> +devscripts package or running your script with an alternate shell such
> +as ``posh`` may help uncover violations of the above requirements. If
> +in doubt whether a script complies with these requirements, use
> +``/bin/bash``.
>
>  Perl scripts should check for errors when making any system calls,
>  including ``open``, ``print``, ``close``, ``rename`` and ``system``.
> diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst
> index 7d9e20a..9574f82 100644
> --- a/policy/ch-opersys.rst
> +++ b/policy/ch-opersys.rst
> @@ -461,19 +461,19 @@ statement at the top of the script, like this:
>  test -f program-executed-later-in-script || exit 0
>
>  Often there are some variables in the ``init.d`` scripts whose values
> -control the behavior of the scripts, and which a system administrator is
> -likely to want to change. As the scripts themselves are frequently
> -``conffile``\ s, modifying them requires that the administrator merge in
> -their changes each time the package is upgraded and the ``conffile``
> -changes. To ease the burden on the system administrator, such
> -configurable values should not be placed directly in the script.
> +control the behavior of the scripts, and which a system administrator
> +is likely to want to change. As the scripts themselves are frequently
> +``conffile``\ s, modifying them requires that the administrator merge
> +in their changes each time the package is upgraded and the
> +``conffile`` changes. To ease the burden on the system administrator,
> +such configurable values should not be placed directly in the script.
>  Instead, they should be placed in a file in ``/etc/default``, which
>  typically will have the same base name as the ``init.d`` script. This
> -extra file should be sourced by the script when the script runs. It must
> -contain only variable settings and comments in SUSv3 ``sh`` format. It
> -may either be a ``conffile`` or a configuration file maintained by the
> -package maintainer scripts. See :ref:`s-config-files` 

Bug#864615: please update version of posix standard for scripts (section 10.4)

[Adam D. Barratt]

On Sat, 2017-10-14 at 11:30 -0700, Sean Whitton wrote:
> control: tag -1 +moreinfo
> 
> Hello Ralf,
> 
> On Sun, Jun 11, 2017 at 06:51:49PM +0200, Ralf Treinen wrote:
> > section 10.4 says:
> > 
> >   Scripts may assume that /bin/sh implements the SUSv3 Shell
> > Command
> >   Language ...
> > 
> > This version of the standard is so outdated that it isn't even any
> > longer available on the opengroup web site.

Really? http://pubs.opengroup.org/onlinepubs/009695399/ is still there,
and indeed referenced from https://en.wikipedia.org/wiki/Single_UNIX_Sp
ecification

> > The latest version of the
> > standard is 4.2 (published in 2016), earlier versions currently 
> > available on the opengroup site are 4 (from 2008) and 4.1 (from
> > 2013).
> > Please consider updating the policy.
> 
> I found the 2016 edition of version 4 of the SUS,[1] but what makes
> you think that is version 4.2?  I couldn't find that version number
> anywhere.  If they've changed their versioning scheme, maybe Policy
> needs to use the expression "SUSv4 (2016 edition)"?

The 2016 edition is Technical Corrigendum 2. I'm not sure that it's
conventional to use versioning such as 4.2 in such cases, however. I'd
expect it to be referred to as SUSv4, SUSv4TC2, or SUSv4 2016 edition;
the latter seems to be more common.

Regards,

Adam

Bug#864615: please update version of posix standard for scripts (section 10.4)

[Sean Whitton]

control: tag -1 +moreinfo

Hello Ralf,

On Sun, Jun 11, 2017 at 06:51:49PM +0200, Ralf Treinen wrote:
> section 10.4 says:
> 
>   Scripts may assume that /bin/sh implements the SUSv3 Shell Command
>   Language ...
> 
> This version of the standard is so outdated that it isn't even any
> longer available on the opengroup web site. The latest version of the
> standard is 4.2 (published in 2016), earlier versions currently 
> available on the opengroup site are 4 (from 2008) and 4.1 (from 2013).
> Please consider updating the policy.

I found the 2016 edition of version 4 of the SUS,[1] but what makes you
think that is version 4.2?  I couldn't find that version number
anywhere.  If they've changed their versioning scheme, maybe Policy
needs to use the expression "SUSv4 (2016 edition)"?

On Sun, Jun 25, 2017 at 04:12:42PM +0200, Guillem Jover wrote:
> On Sun, 2017-06-11 at 20:46:23 +0200, Bill Allombert wrote:
> > Before doing that, we have to check whether all the relevant packages
> > are compliant with this update.
> 
> Well, I don't all of our current shell packages are even compliant with
> the current version specified in policy.
> 
> dash is one of such packages, with several non-compliancy bugs. And given
> that it is our default shell…

Concur.  If we're not in compliance now, this Policy update does not
immediately make packages buggy.  And people will be far more motivated
to bring their packages into compliance if they're being asked to bring
them into compliance with the latest version of the standard.

[1]  http://pubs.opengroup.org/onlinepubs/9699919799/toc.htm

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#864615: please update version of posix standard for scripts (section 10.4)

[Guillem Jover]

On Sun, 2017-06-11 at 20:46:23 +0200, Bill Allombert wrote:
> On Sun, Jun 11, 2017 at 06:51:49PM +0200, Ralf Treinen wrote:
> > Package: debian-policy
> > Version: 4.0.0.0
> > Severity: normal

> > section 10.4 says:
> > 
> >   Scripts may assume that /bin/sh implements the SUSv3 Shell Command
> >   Language ...
> > 
> > This version of the standard is so outdated that it isn't even any
> > longer available on the opengroup web site. The latest version of the
> > standard is 4.2 (published in 2016), earlier versions currently 
> > available on the opengroup site are 4 (from 2008) and 4.1 (from 2013).
> > Please consider updating the policy.

> Before doing that, we have to check whether all the relevant packages
> are compliant with this update.

Well, I don't all of our current shell packages are even compliant with
the current version specified in policy.

dash is one of such packages, with several non-compliancy bugs. And given
that it is our default shell…

Thanks,
Guillem

Bug#864615: please update version of posix standard for scripts (section 10.4)

[Ralf Treinen]

Hi Bill,

On Sun, Jun 11, 2017 at 08:46:23PM +0200, Bill Allombert wrote:
> On Sun, Jun 11, 2017 at 06:51:49PM +0200, Ralf Treinen wrote:
> > Package: debian-policy
> > Version: 4.0.0.0
> > Severity: normal
> > 
> > Hello,
> > 
> > section 10.4 says:
> > 
> >   Scripts may assume that /bin/sh implements the SUSv3 Shell Command
> >   Language ...
> > 
> > This version of the standard is so outdated that it isn't even any
> > longer available on the opengroup web site. The latest version of the
> > standard is 4.2 (published in 2016), earlier versions currently 
> > available on the opengroup site are 4 (from 2008) and 4.1 (from 2013).
> > Please consider updating the policy.
> 
> Hello Ralf,
> 
> Before doing that, we have to check whether all the relevant packages
> are compliant with this update.
> 
> This requires that someone reviews all packages that provide /bin/sh to
> check whether they implement SUSv4.
> The difference between SUSv3 and SUSv4 need to be listed to check
> whether this can affect any shell script that rely on SUSv3

Thanks for your answer. I agree with that course of action. However, I
was unable to find a document describing the difference between susv3 and
susv4.1. The HTML documents of the standard are not diff-able, so maybe we
should ask on the opengroup mailing list.

-Ralf.
-- 
Ralf Treinen
Institut de Recherche en Informatique Fondamentale
Équipe Preuves, Programmes et Systèmes
Université Paris Diderot, Paris, France.
http://www.irif.fr/~treinen/

Bug#864615: please update version of posix standard for scripts (section 10.4)

[Bill Allombert]

On Sun, Jun 11, 2017 at 06:51:49PM +0200, Ralf Treinen wrote:
> Package: debian-policy
> Version: 4.0.0.0
> Severity: normal
> 
> Hello,
> 
> section 10.4 says:
> 
>   Scripts may assume that /bin/sh implements the SUSv3 Shell Command
>   Language ...
> 
> This version of the standard is so outdated that it isn't even any
> longer available on the opengroup web site. The latest version of the
> standard is 4.2 (published in 2016), earlier versions currently 
> available on the opengroup site are 4 (from 2008) and 4.1 (from 2013).
> Please consider updating the policy.

Hello Ralf,

Before doing that, we have to check whether all the relevant packages
are compliant with this update.

This requires that someone reviews all packages that provide /bin/sh to
check whether they implement SUSv4.
The difference between SUSv3 and SUSv4 need to be listed to check
whether this can affect any shell script that rely on SUSv3

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#864615: please update version of posix standard for scripts (section 10.4)

[Ralf Treinen]

Package: debian-policy
Version: 4.0.0.0
Severity: normal

Hello,

section 10.4 says:

  Scripts may assume that /bin/sh implements the SUSv3 Shell Command
  Language ...

This version of the standard is so outdated that it isn't even any
longer available on the opengroup web site. The latest version of the
standard is 4.2 (published in 2016), earlier versions currently 
available on the opengroup site are 4 (from 2008) and 4.1 (from 2013).
Please consider updating the policy.

Thanks -Ralf.


-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.utf8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.utf8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

debian-policy depends on no packages.

debian-policy recommends no packages.

Versions of packages debian-policy suggests:
ii  doc-base  0.10.7

-- no debconf information