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

[Jacob Bachmeyer]

Zack Weinberg wrote:
> On Sun, May 23, 2021 at 12:19 AM Jacob Bachmeyer <jcb62281@gmail.com> 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
>
> var=`expression`
>
> 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.

> and
>
> 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
> project.)

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