On Sun, Feb 24, 2019 at 11:22 PM Robert Elz <k...@munnari.oz.au> wrote:
> 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.
Apologies to Chet if I'm bringing up issues with something that still
a WIP. The two older commits I mentioned were changes to bring a great
number of things in compliance with interpretation 888 and the corner
case bugs I mention above are AFAICT casualties of those fixes. I
think the latest changes in the devel branch made as a result of the
report you mention made expansion on the RHS of parameter expansion
more consistent with behavior outside of PE, and that includes this
variance in corner case behavior.
> I assume you mean ${_+"$@"''} and ${_+''"$@"} ?
Sorry about that, yup those are what I meant to put in.
> 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'
Yup I was referencing the devel version that fixed the ${b+s ''} issue.
> | 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).
I think I'm missing something but how can that be the case regarding
the quoting?
For example "${x+" a b "}" expands to a single field in
bash/dash/yash/zsh/netbsd sh (though not in ksh..)
> 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.)
The use case I could imagine is something like "${a[@]-${b[@]}}" where
you want to produce a field for every element of ${a[@]} unless it's
unset, in which case a field for every element of ${b[@]}. Or, less
plausably, "${x-$@}", where, if x is set, it should not be subject to
field splitting, etc.
Looks like when there are one or more positional parameters (and x
unset) all shells listed above expand "${x-$@}" to the proper number
of fields, but only yash expands it to zero fields when there are no
params. I don't know if that behavior is intentional but I guess
bash's behavior matching the others' makes sense.
> but that's because they don't
> implement $_ (and good on them for that, stupid thing it is)
Sorry, didn't mean to confuse the issue by using _, should've used a
more portable example.
