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

[Zack Weinberg]

On Sun, May 23, 2021 at 12:19 AM Jacob Bachmeyer <jcb62281@gmail.com> wrote:
> Zack Weinberg wrote:
> > I fully endorse reverting config.{sub,guess} to classic backtick
> > command substitutions.
>
> Thank you for your support.
>
> > However, Autoconf proper (in 2.70+) will continue to look for $(...)
> > support in its “better shell” logic. This is because, even before the
> > 2.70 release, a steadily increasing number of configure.ac
> > <http://configure.ac>’s and  third party macros were casually using
> > it, having never been tested with shells that don’t support it.
>
> That is less of a problem, since modern systems do have such a shell
> /somewhere/; however, Autoconf should probably mention an old release of
> bash (that /can/ be built on a system with a pre-POSIX shell) in the "no
> better shell" found message.

Good thought, filed as <https://savannah.gnu.org/support/?110497>.  (I
don't currently have any cycles for autoconf work.)

[...]
> On this I disagree; I believe that omitting those quotes is easier to read.
[...]
> > “*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

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.

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.

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

zw