On Mon, May 24, 2021 at 9:31 PM Jacob Bachmeyer <jcb62...@gmail.com> wrote: > Zack Weinberg wrote: > > On Sun, May 23, 2021 at 12:19 AM Jacob Bachmeyer <jcb62...@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. > 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 lacking here. zw
