Date: Sun, 17 Feb 2019 20:07:06 -0500
From: Chet Ramey <chet.ra...@case.edu>
Message-ID: <71d1418e-54a1-ddd4-6467-cbc27122e...@case.edu>
| The idea behind the bash behavior is that a
| null string added to a non-empty word is simply discarded,
This is clearly not POSIX compliant behaviour - POSIX requires that words
be accumulated as entered (seemingly redundant null strings or not)
and that quotes only get removed after field splitting has happened.
Of course, no-one cares how it is actually implemented, but the
effect has to be the same.
What's more, it is obvious that this doesn't happen consistently:
jinx$ x=abc
jinx$ xy=def
jinx$ echo $x''y
abcy
jinx$
(That's bash 5, but any other vers would do the same I think ... it is
also correct).
There the null string is being added to a non-empty word, but is
(correctly) not simply being discarded (or when it comes to time
to expand the var, xy would be expanded instead of x).
Similarly, bash does "$@"'' correctly. If there are no args ($# = 0)
then the "$@" vanishes, but the '' remains. Again, '' was appended
to a non-empty word, and is (correctly) not discarded - if it had been
then all that would be left would be "$@" which would produce nothing
at all, which would not be correct here.
[If $# != 0 the '' ends up being appended to the value of (what is
effectively) ${$#} (though that's not legal syntax, except maybe in zsh)
whereupon when quote removal happens, it vanishes.]
There are plenty more examples where null strings aren't simply disarded,
and I cannot think of any particularly good reason why the particular case
in question should be treated differently.
It is also clear that quotes in a situation like this aren't simply
being ignored in general:
jinx$ args ${PATH+a "b c"}
2: <a> <b c>
which is also correct. Why are quotes around this one more important
than those in "" ?
It is actually wprse than it seems, as:
jinx$ x=
jinx$ args ${PATH+a "$x"}
1: <a>
jinx$ x=b
jinx$ args ${PATH+a "$x"}
2: <a> <b>
jinx$ args ${PATH+a "$( : )"}
1: <a>
It isn't just an explicit null string that is discarded, but
as that example shows, anything that ends up being null. This
is clearly a bug (whatever ksh93 does ... that has plenty of
other bugs). In the last of those it cannot really even be known
wether the result of the command substitution will be null or not
until it is evaluated (it could cotain a much more complicated
command than shown here, which only sometimes generates nothing).
Quoted null strings should never simply be discarded - not until
quote removal anyway when it is too late to make the word
containing it vanish, even if it contains nothing else.
kre
