From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1110 invoked from network); 7 May 1999 13:37:00 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 7 May 1999 13:37:00 -0000 Received: (qmail 28242 invoked by alias); 7 May 1999 13:36:40 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6234 Received: (qmail 28235 invoked from network); 7 May 1999 13:36:40 -0000 Date: Fri, 7 May 1999 15:36:36 +0200 (MET DST) Message-Id: <199905071336.PAA12641@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: Peter Stephenson's message of Fri, 07 May 1999 13:51:47 +0200 Subject: Re: BUG: zsh-3.1.5-pws-14: parameter expansion not working properly 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@informatik.hu-berlin.de