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` for > -more details. > +extra file should be sourced by the script when the script runs. It > +must contain only variable settings and comments in SUSv4 (2016 > +edition) ``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. > > To ensure that vital configurable values are always available, the > ``init.d`` script should set default values for each of the shell -- Sean Whitton
Attachment:
signature.asc
Description: PGP signature