Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: BUG: zsh-3.1.5-pws-14: parameter expansion not working properly
- X-seq: zsh-workers 6234
- From: Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxxxxxx
- Subject: Re: BUG: zsh-3.1.5-pws-14: parameter expansion not working properly
- Date: Fri, 7 May 1999 15:36:36 +0200 (MET DST)
- In-reply-to: Peter Stephenson's message of Fri, 07 May 1999 13:51:47 +0200
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
Peter Stephenson wrote:
> Sven Wischnowsky wrote:
> >
> > [ There is a little patchlet below. I don't suggest using it to
> > everyone just now, it's just that I can think about this better when
> > I have cod to play with. Didn't have the time for this yesterday. ]
>
> Is there any agreement on this patch (6046) to introduce the variable
> mult_isarr to keep track of whether a nested parameter substitution returns
> an array? If so, what documentation changes are needed (which might help
> tell everyone else what it's doing)? And what about the other glitch that
> was noticed, that a single word array is always turned into a scalar
> (currently around line 1471 in subst.c), do we get rid of that for
> consistency? And do either of these require any changes to the existing
> shell code in the distribution?
Ah, this was on my todo-list, too.
Quick description just to make sure that anyone knows what we are
talking about: without that patch "${${(@)a}[1,2]}" with `a' being
an array, the subscript works on a *string*, the concatenated elements
of `a', even though there is a `(@)' flag. To get subscription on the
array elements, one has to add a second `(@)' flag in the outer
expansion. Another effect is that with the patch "${(@)${a}[1,2]}"
behaves like "${${a}[1,2]}". Without the patch this (somewhat
irritatingly) gives all elements of the array concatenated in one
string, because there the `(@)' made the inner expansion return an
array of one element.
Changes in the documentation that would be needed:
Point 1.: the value returned is not always an array, only if the inner
expansion would yield one (w.r.t to quoting and whatnot)
The first `foo' example ("${(@)${foo}[1]}"): see above, the inner
"${foo}" produces a string and subscripting yields `b'
The second example ("${${(@)foo}[1]}"): produces `bar', because the
inner "${(@)foo}" yields an array which is then subscripted
[Btw. point 2. is still wrong (multiple subscripts always work on the
result from previous subscripts, the parameter need not be an array).]
About the singleton-array-to-scalar-conversion: this irritated me,
too, the patch for 6046 sets mult_isarr earlier than I would have done
it if this piece of code weren't there. I haven't played enough with
it to find out when exactly this is useful (if it is at all).
About changes needed in the shell code: I once had this patch in my
version, of course. I used as a normal working shell and the
completion functions at least didn't suffer from it. But they (almost?)
always use the `(@)' flag on every level and the behavior for that
wasn't changed. I haven't tried all example shell code stuff we have,
but a quick `grep @ ...' looks good (we don't use subscripts on nested
parameter expansion very often, it seems).
Maybe Bart could give some more help here...
Bye
Sven
--
Sven Wischnowsky wischnow@xxxxxxxxxxxxxxxxxxxxxxx
Messages sorted by:
Reverse Date,
Date,
Thread,
Author