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 > > -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
Attachment:
signature.asc
Description: PGP signature