Re: BUG: zsh-3.1.5-pws-14: parameter expansion not working properly

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Bart Schaefer wrote:

> Now that I've seen/used it in practice a few times, I'm not so sure any
> more.  The more radical change, and one which bothers me a lot, is the
> effect when the array has more than one element:
> 
> 	foo=(xa yb zc)
> 	print -l "${${(@)foo}[1]}" "${(@)${foo}[1]}"
> 
> Zsh 3.0.5 prints
> 
> 	xa
> 	x
> 
> But 3.1.5-pws-14 prints
> 
> 	x
> 	xa
> 
> That's completely reversed the semantics, and thus is a serious problem.

(Do you really get `xa' in the last case?)

This (and the need to repeat the `(@)') comes from the fact that
multsub() doesn't get any information about where the words came
from. I.e. if they are an `array' (even if only one string) or not. I
already said this at least once. To solve this better we would need a
way to make `paramsubst()' notify `multsub()' if the thing is an
array. This could be done by using a subst.c-global variable that is
set in multsub() and paramsubst() and tested in multsub() after
prefork(), of course.
And then we would have to decide when we want to accept an array at
the call of multsub(). Always, if the sub-expression is an array? Even
if the whole thing is in double quotes? If it is in double quotes and
we don't want it always, when? Hm, maybe when the `(@)' flag is given
or the things came from an array. But then there would be no way to
make an array be treated as a scalar further down up then by using
the `(j:...:)' flag. But then again, this may be ok.

Or maybe we make the inner expression be taken as an array if it is a
parameter expansion that results in an array and make it be used as a
scalar value in all other cases, independent of quoting (which means
that the quoting will only have it's normal effect on the inner
expressions). That way the `(@)' has only an effect to the `outside',
not on the treatment of an inner expression when given in an outer
one (something I already described -- and didn't like, too). This
would give the same as 3.0.5 again for your example above, with the
`x' returned as an array, which noone will notice (and the `(@)'
wouldn't have any effect in `"${(@)${foo}[1]}"').

There may be other problems I don't see, though (apart from changing
the manual again).

Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx