[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: Thu, 27 May 2021 20:56:18 -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 Mon, May 24, 2021 at 9:31 PM Jacob Bachmeyer <> wrote:
Zack Weinberg wrote:
On Sun, May 23, 2021 at 12:19 AM Jacob Bachmeyer <> 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.

I still disagree.

OK, so, I'm willing to accept


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

case "$result" in

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

Why? The purpose of quotes in the shell is to allow a single WORD to contain whitespace or other field separators. The RHS of an assignment and the data field in "case" are both places that only allow a single WORD, therefore variable expansions and command substitutions are implicitly quoted in those contexts. If nothing else, never quoting these explicitly helps to remind that splitting and glob expansion /are/ /not/ /done/ in those contexts, avoiding "why did this not work?" questions.

Nor can you reliably check for error exits from all of the commands run, unless you have an entire retrocomputing museum available to verify that none of the obscure commands used on various obscure systems return a valid result and an error exit code.

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

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

Code style rules that ignore (or work against) underlying language rules are uncomfortably close to cargo cult programming for my tastes. The shell does not recognize that intent, but instead performs word-splitting in certain contexts (such as building argument lists for commands) and not in others (were only one word is allowed anyway).

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.

Except that splitting is only available in certain contexts, so the contextual rules are still important, even if you prefer to pretend that they do not exist.

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

I prefer otherwise unconditionally. I may use your style if I ever contribute code to Autoconf, at least to match the style in existing code, but I consider this rule to be silly.

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.

Quoted strings have higher priority than variable substitutions and I do not understand the Emacs syntax highlighting machinery well enough yet to even attempt to change that.

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

What need is there for that for something this simple? Can not the maintainer take care of testing submitted patches?

-- Jacob

reply via email to

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