bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "$@" expansion when it is consists of only null strings


From: Grisha Levit
Subject: Re: "$@" expansion when it is consists of only null strings
Date: Mon, 25 Feb 2019 17:38:07 -0500

On Sun, Feb 24, 2019 at 11:22 PM Robert Elz <address@hidden> 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 "address@hidden"
>   |     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 "address@hidden@]}}" where
you want to produce a field for every element of address@hidden unless it's
unset, in which case a field for every element of address@hidden  Or, less
plausably, "address@hidden", 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 "address@hidden" 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]