Bug#864615: please update version of posix standard for scripts (section 10.4)
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 <http://www.unix.org/version3/online.html>`_ 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
> > + <http://pubs.opengroup.org/onlinepubs/9699919799/download/>`_.
> >
> > .. [#]
> > 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.
Reply to: