[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 0/6] restore compatibility with pre-POSIX shells in

From: Jacob Bachmeyer
Subject: Re: [PATCH 0/6] restore compatibility with pre-POSIX shells in config.guess
Date: Mon, 24 May 2021 20:31:40 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20090807 MultiZilla/ SeaMonkey/1.1.17 Mnenhy/

Zack Weinberg wrote:
On Sun, May 23, 2021 at 12:19 AM Jacob Bachmeyer <> wrote:
Zack Weinberg wrote:
“*All* shell variable interpolations will be inside double quotes,
except when word splitting of the result is *desired*” puts less
cognitive load on people reading the script than “shell variable
interpolations will only be inside double quotes when word splitting
is both possible and undesirable.“ Thus it is the style rule I’ve been
applying in Autoconf proper, and I think it’s appropriate here as well.
I disagree, and I have a very good technical reason:  backticks
containing double quotes inside double quotes are non-portable due to
bugs in various older shells.  Many of the command substitutions use
echo to pipe a variable's value through sed and need that variable
quoted.  Therefore, backticks need to be in non-quoted contexts, which
the preparatory patches earlier in the series arrange.

OK, so, I'm willing to accept


being written without an outer set of double quotes, but I insist on
this being the _only_ exception; in particular I insist on

case "$var" in ... esac

There are also uses of "case `command` in ... esac" in config.guess. The same technical reason for omitting quotes in "var=`command`" also apply when `command` is the WORD in a case construct.


var="anything that doesn't involve backticks and isn't better written
with single quotes"

being written _with_ the double quotes.  I will bow to additional
exceptions only when there are other bugs in older shells that
_require_ us not to use double quotes around variable substitutions.

Your example for a variable assignment legitimately requires quotes, since you have multiple literal words on the right-hand side of the assignment, variable assignment is NAME=WORD in the shell, and quotes allow WORDs to contain whitespace or other field separators. However, there is no need to use quotes when expanding variables in an assignment that is a single literal word, since the shell does not perform word-splitting in contexts where only one word is permitted.

Concerning matters of readability, there is less concern with Autoconf since Autoconf builds up shell scripts using m4 macros and about no one is expected to read or edit a configure script produced by Autoconf. Autoconf also has more complex quoting rules in input, since there is both m4 and shell quoting to manage. As such, your style works well with Autoconf, but I do not believe that it works as well with scripts that are intended to be hand-edited. Using double quotes is never a problem in POSIX shells, particularly with the $( ) command substitution syntax, but config.guess must be both hand-edited and runnable under pre-POSIX shells, since it purports to identify a variety of pre-POSIX systems. Lastly, Emacs produces better syntax highlighting, clearly showing the actual variables being substituted, if the expression is unquoted. Again, this is less of a concern for Autoconf for other reasons, but is more relevant when the shell script is intended to be hand-edited.

These particular scripts, as you know, have extra-strong constraints
on what shell constructs they can use.  What you might not appreciate
is that they also have extra-strong constraints on _how they can be
styled_, because they are most frequently edited by people in a hurry,
trying to bring up a new operating system, needing to define a new
canonical system name for it.  They are usually _not_ experts in the
dark history of Bourne shell.  They cannot be relied on to run
shellcheck before submitting a patch, or test on any system or shell
but the one most conveniently to hand.  They _can_ usually be relied
on to make an attempt to match the style of the surrounding code, but
they do not, and should not be expected to, infer subtle style rules
like the one you are proposing.  If we do it my way, I think future
submissions will have a much better chance of being correct.

I can add a brief style guide in a comment block easily enough.

(N.B. arguments from the availability of shellcheck would cut rather
more ice with me if we had _any form whatsoever_ of CI in this

There is a testsuite that can be easily run with "make check-guess", although some tests will fail on non-GNU systems, as the code paths for identifying GNU variants tend to assume that GNU tools are available.

-- Jacob

reply via email to

[Prev in Thread] Current Thread [Next in Thread]