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

[Jacob Bachmeyer]

Zack Weinberg wrote:
> On Sat, May 22, 2021 at 9:06 PM Jacob Bachmeyer <jcb@gnu.org 
> <mailto:jcb@gnu.org>> wrote:
>
>     This patch series tidies config.guess and reverts to classic backtick
>     command substitutions.
>
>
> 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.

>     No shell splits the WORD in "case WORD in ... esac", so instances
>     where WORD was quoted were changed.
>
>
> This change, however, I think is a mistake, because it’s easier to 
> *read* shell scripts if you don’t make the reader remember this syntax 
> quirk.

On this I disagree; I believe that omitting those quotes is easier to read.

This is somewhat a matter of style, and I prefer the way Emacs syntax 
highlights the unquoted form.  Since the script was previously 
inconsistent and I was writing the patches, I chose to make the script 
consistent in my preferred style.  There is also a technical reason for 
using the unquoted form, see below for details.

>     Quotes while forming the output are pointless, since no valid GNU
>     configuration tuple contains whitespace, therefore no variables
>     interpolated will be candidates for word splitting.
>
> [and several other tricks to avoid putting shell variable 
> interpolation inside double quotes]
>
> And again, I think you shouldn’t make people remember or deduce that.

They do not need to recognize that, which is why I did not add a comment 
explaining those details in the script.  Instead, I moved the 
interpolations to contexts where quoting is not required.  Following the 
existing patterns in the script will allow future additions to fit in 
transparently, and "shellcheck" will catch mistakes here.

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

The rule is very simple:  place shell variables inside double quotes 
unless word-splitting is desired and available, or the expansion is in a 
context where word-splitting does not occur.  You need to remember that 
variable assignments and case constructs do not do word-splitting 
because another rule is "do not quote backticks" to maintain portability.
This rule need not even be remembered:  the "shellcheck" tool will 
provide reminders about variables not quoted where they should be quoted.


-- Jacob