[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: Sat, 22 May 2021 23:18:59 -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 Sat, May 22, 2021 at 9:06 PM Jacob Bachmeyer < <>> 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 <>’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

reply via email to

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