On Mon, May 24, 2021 at 9:31 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote:
Zack Weinberg wrote:
On Sun, May 23, 2021 at 12:19 AM Jacob Bachmeyer <jcb62281@gmail.com> 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
result=`command`
case "$result" in
...
esac
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
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
permitted.
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
word-split.
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
unconditionally.