Zack Weinberg wrote:
On Sat, May 22, 2021 at 9:06 PM Jacob Bachmeyer <j...@gnu.org
<mailto:j...@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
