Date: Sun, 24 Feb 2019 18:37:33 -0500
From: Grisha Levit <grishale...@gmail.com>
Message-ID:
<CAMu=brqkmx7pfgarh2dnax3tbfarhutuvvq+o3e+mmx165s...@mail.gmail.com>
| There are some what seem to be regressions (?) in bash-4.4 and
| bash-5.0 regarding the handling of "$@" expansion when it consists
| entirely of null strings.
I think these are actually more the insertion of explicit null
strings, rather than $@ when it contains null strings. These
are essentially the same as the ${b+s ''} issue that was discussed
a week or so ago, and which Chet already said he would look into.
| $ set -- ''
| $ n "$@"''
| 0
Should be 1. It would be if the '' null string was not there.
| $ set -- '' ''
| n ''"$@"
| 1
Should be 2. $1 gets obliterated by the '' and $2 remains.
| n "$@"''
| 1
Same (should be 2) except here $1 remains and $2 is lost.
| n ''"$@"''
| 0
Again, should be 2, here both $1 and $2 are lost.
Of course if you just did
n "$@"
you'd get 2 as you should (no explicit null strings to kill the $@ expansions).
| $ set -- ''
| $ n ${_+''"$@"''}
| 0
Should be 1
| $ n ${_+"$@" "$@"}
| 1
Should be 2. Not sure what is up with that one as there
are no explicit null strings to confuse things. Each $@ should
expand to (quoted) $1 (even though that means ""), which is then
field split at the (unquoted) space to leave 2 null string args.
| On a related note, with $#=0, bash-20190220 fixed the expansion of
| ${_"$@"''} and ${''"$@"} to produce a single field but not so with:
I assume you mean ${_+"$@"''} and ${_+''"$@"} ? But even bash2 got
those correct (they're both 1). bash5 gets the 2nd one wrong (0)
but I might be testing an older version than you meant had fixed it
(I do not build development versions.) BASH_VERSION='5.0.0(1)-release'
| $ set --
| $ n ${_+''"$@"''}
| 0
Should also be 1.
| And these have always been the case, but I'm not sure if it should be so?
|
| $ set --
| $ n "${_+"$@"}"
| 1
| $ n "${_+$@}"
| 1
Those are, I believe, unspecified cases. The first is definitely
because of the strange quoting (the " chare are in order, open, close,
open, close, not open open close close). Anything could replace the
$@ in that (even just x ) and you'd still get unspecified results.
The second because there's no real agreement whether it should produce
0 or 1 (different shells do different things for that one, and there's
no particularly good argument for one or the other, so posix, I believe,
makes that one unspecified as well.)
kre
ps: for a couple of the last of those (before the unspecified ones)
bosh and yash seem to get them wrong as well, both giving 0 for both of
n ${_+''"$@"''} and n ${_+"$@" "$@"} ... but that's because they don't
implement $_ (and good on them for that, stupid thing it is), so the
word after the "+" isn't used unless one does _=X or similar first.
bosh still gets n ${_+"$@" "$@"} wrong though (0), even when _ is set.
