From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1344 invoked from network); 1 Jun 1999 17:44:51 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 1 Jun 1999 17:44:51 -0000 Received: (qmail 25220 invoked by alias); 1 Jun 1999 17:44:42 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6426 Received: (qmail 25213 invoked from network); 1 Jun 1999 17:44:38 -0000 From: "Bart Schaefer" Message-Id: <990601174432.ZM11100@candle.brasslantern.com> Date: Tue, 1 Jun 1999 17:44:32 +0000 In-Reply-To: <9906010956.AA18502@ibmth.df.unipi.it> Comments: In reply to Peter Stephenson "PATCH: pws-19: document minor syntactic innovation" (Jun 1, 11:56am) References: <9906010956.AA18502@ibmth.df.unipi.it> X-Mailer: Z-Mail (5.0.0 30July97) To: zsh-workers@sunsite.auc.dk (Zsh hackers list) Subject: Re: PATCH: pws-19: document minor syntactic innovation MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Jun 1, 11:56am, Peter Stephenson wrote: } Subject: PATCH: pws-19: document minor syntactic innovation } } I should note that things like ${"foo"} only work by accident: you'll find, } for example, that ${"foo"%bar} doesn't work. That would require swallowing } nulled out quotes at another point in paramsubst(), which I hinted at } before. I didn't do this because I didn't see a use for it, but maybe it's } more consistent that way? If it's messy, I think it could be left out, but yes, it is more consistent that way. } > What's the right way to document this change, including odd stuff like } > the above? } } Here's a possible chunk for 3.1.5-pws-20. [...] } +Note that double quotes may appear around nested quotations, in which case Perhaps "nested expansions" rather than "nested quotations"? } > Should the FAQ recommend using this form in some circumstances because } > of the (@) change in 3.1.5? } } Well, the new nested substitution section (3.22) is really about getting a } parameter evaluated as a parameter name and I'm not sure it's a good idea } to put in a lot of stuff about other flags and their uses, which could get } quite involved. Maybe it needs a separate question, but I'm not sure I can } even remember the full effect of the changes. The full effect of the (@) changes? It's pretty simple, really. In 3.0, once something becomes an array as a result of (@) or (f) or (s//), it is always an array, even inside quotes, no matter how deeply nested the ${ } get. In 3.1.5-pws-XX for XX > 15 (I think it was), array-ness persists only for the current level of ${ }; if there's another ${ } around that, quoted-ness takes over again. So to get certain quoted array expansions to behave the same in 3.0.6 and 3.1.5-pws-20+, you must either put in an (@) at every ${ } (which is ugly and, in 3.0.6, redundant), or you must `push in the quotes' as deeply into the nested ${ } as possible, e.g. to immediately surround the ${(@)...}. For example, in 3.0.6-pre-4 and later, the following all are (will be) equivalent: "${${${(f)$(print -l *)}}}" (1) ${"${${(f)$(print -l *)}}"} (2) ${${"${(f)$(print -l *)}"}} (3) ${${${(f)"$(print -l *)"}}} (4) In 3.1.5-pws-20, (1) == (2) [both are strings] and (3) == (4) [both are arrays], but [obviously] (1) != (4). Oh, and of course the [@] subscript and subscript number ranges behave just like the (@) flag as far as this is concerned. I admit I haven't worked out whether there are other ramifications when SH_WORD_SPLIT is set .... -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com