From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28549 invoked from network); 9 May 1999 17:50:42 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 9 May 1999 17:50:42 -0000 Received: (qmail 17159 invoked by alias); 9 May 1999 17:50:28 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6243 Received: (qmail 17151 invoked from network); 9 May 1999 17:50:26 -0000 From: "Bart Schaefer" Message-Id: <990509104940.ZM21070@candle.brasslantern.com> Date: Sun, 9 May 1999 10:49:40 -0700 In-Reply-To: <9905071151.AA42253@ibmth.df.unipi.it> Comments: In reply to Peter Stephenson "Re: BUG: zsh-3.1.5-pws-14: parameter expansion not working properly" (May 7, 1:51pm) References: <9905071151.AA42253@ibmth.df.unipi.it> <199905071336.PAA12641@beta.informatik.hu-berlin.de> In-Reply-To: <199905071336.PAA12641@beta.informatik.hu-berlin.de> Comments: In reply to Sven Wischnowsky "Re: BUG: zsh-3.1.5-pws-14: parameter expansion not working properly" (May 7, 3:36pm) X-Mailer: Z-Mail (4.0b.820 20aug96) To: zsh-workers@sunsite.auc.dk Subject: Re: BUG: zsh-3.1.5-pws-14: parameter expansion not working properly MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On May 7, 1:51pm, Peter Stephenson wrote: } Subject: Re: BUG: zsh-3.1.5-pws-14: parameter expansion not working proper } } 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? I think it's more sensible behavior than what's happening now. It's a little less likely to break scripts written for 3.0.x, too. } If so, what documentation changes are needed (which might help } tell everyone else what it's doing)? We'd have to revise the "parameter expansion rules" section that you added. In particular, the latter part of this: 1. *Nested Substitution* If multiple nested `${...}' forms are present, substitution is performed from the inside outwards. At each level, the substitution takes account of whether the current value is a scalar or an array, whether the whole substitution is in double quotes, and what flags are supplied to the current level of substitution; the flags are not propagated up to enclosing substitutions. The value passed back to an enclosing substitution is always an array, which however will consist of one word if the value was not itself an array. All the following steps take place where applicable at all levels of substitution. Becomes (see Sven's note): ... the current level of substitution, just as if the nested substitution were the outermost. The flags are not propagated up to enclosing substitutions; nor are arrays joined into strings, nor strings split into arrays, except as indicated by the flags at the current level as adjusted for quoting. All the following steps take place where applicable at all levels of substitution. I don't know whether we'd want to add something like: Note that, unless the (P) flag is present, the flags and any subscripts at each enclosing substitution apply directly to the value of the nested substitution. Then as Sven mentioned: 2. *Parameter Subscripting* If the value is a raw parameter reference with a subscript, such as ${VAR[3]}, the effect of subscripting is applied directly to the value of the parameter. Subscripts are evaluated left to right; each second and succeeding subscript applies to the value yielded by the previous subscript. Thus, if VAR is an array, ${VAR[1][2]} is the second character of the first word, but ${VAR[2,4][2]} is the entire third word (the second word of the range of words two through four of the original array). Perhaps an example should note that ${foo[2,4][2]} == ${${foo[2,4]}[2]} (No quotes!) ${${foo[2,4]}[2]} != "${${foo[2,4]}[2]}" (Quotes matter) ${${foo[2,4]}[2]} == "${${(@)foo[2,4]}[2]}" ((@) matters) And finally, the example changes Sven described. } 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? I tried deleting that and got a core dump elsewhere in subst.c. There's a loop over the array that assumes index 1 must not be null because it's not possible (when the line-1471-code is present) to get there with a 1- element array. I haven't worked out whether there are other consequences to stopping that loop sooner. I think we should correct it, but there's almost certainly some reason for it, perhaps now lost in the mists of time. On May 7, 3:36pm, Sven Wischnowsky wrote: } Subject: Re: BUG: zsh-3.1.5-pws-14: parameter expansion not working proper } } 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). Right. The only good alternatives at this point are probably [a] go back to the 3.0 behavior of (@), or [b] leave it the way this mult_isarr patch leaves it. Can anyone think of something in between that makes sense? -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com