[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 0/6] restore compatibility with pre-POSIX shells in config.gu
Re: [PATCH 0/6] restore compatibility with pre-POSIX shells in config.guess
Thu, 27 May 2021 14:16:17 -0400
On Mon, May 24, 2021 at 9:31 PM Jacob Bachmeyer <email@example.com> wrote:
> Zack Weinberg wrote:
> > On Sun, May 23, 2021 at 12:19 AM Jacob Bachmeyer <firstname.lastname@example.org> 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.
> > 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
> 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`.
> > 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
> 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
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.
> 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
> 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.
> > (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.)
> 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