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

[Zack Weinberg]

On Mon, May 24, 2021 at 9:31 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote:
> 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*”

is still the overarching principle I am insisting on.

> > 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.

How about we turn all of those into

result=`command`
case "$result" in
  ...
esac

and, generalizing, use command substitution _only_ as the RHS of an
assignment to a variable?  In addition to eliminating an additional
exception to the above principle, this will facilitate future changes
to check for errors in all of the `commands`.

> > 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,

That wasn't meant to be taken as a literal example, it was meant to be
taken as a statement of the rule: the right hand side of a variable
assignment shall _always_ be quoted, even if the quoting is
technically unnecessary.  Use single quotes whenever possible,
backquotes for command substitution (in which case the RHS of the
assignment should be a _single_ command substitution and nothing else),
and double quotes for any RHS requiring variable substitution.

I _might_ consider allowing the RHS not to be quoted when it is an
integer constant.

> 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.

I am saying that I want the quotation to be there _even though_ it's
not technically necessary.  The only time a shell variable expansion
shouldn't be quoted is when that expansion is _intended_ to be
word-split.

I do not want to have to think about the contextual rules for whether
an expansion will, or will not, happen; I only want to have to think
about whether an expansion _should_ happen, which is a function of the
variable itself, not the context where it's being used.

...
> 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.

I developed this style rule _for_ hand-edited scripts, long before I
ever started hacking on Autoconf; it's entirely about not having to
think about whether it is "safe" to leave the quotes off.  I prefer it
unconditionally.

> Emacs produces better syntax highlighting, clearly showing the
> actual variables being substituted, if the expression is unquoted.

That sounds like something that should be fixed in Emacs.

> > (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.

It's the _automatic_ running of tests on submitted patches that is
lacking here.

zw