From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12423 invoked from network); 19 Apr 2001 15:00:31 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 19 Apr 2001 15:00:31 -0000 Received: (qmail 25694 invoked by alias); 19 Apr 2001 15:00:22 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 14035 Received: (qmail 25681 invoked from network); 19 Apr 2001 15:00:22 -0000 Date: Thu, 19 Apr 2001 17:00:14 +0200 To: zsh-workers@sunsite.dk Cc: 92780@bugs.debian.org, Bart Schaefer Subject: Re: requests Message-ID: <20010419170014.B1824@Amber.lab.icm.edu.pl> References: <20010414202410.A10021@dman.com> <1010415032859.ZM27364@candle.brasslantern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: <1010415032859.ZM27364@candle.brasslantern.com>; from Bart Schaefer on Sun, 15 Apr 2001 03:28:58 +0000 X-PGP: 1024D/D619540D; A0E5 7DA4 56B5 8171 42FA 8F8F BED1 B3E7 D619 540D; 2000-03-17 -- 2002-03-17 From: Michal Politowski Sender: Michal Politowski On Sun, 15 Apr 2001 03:28:58 +0000, Bart Schaefer wrote: > On Apr 14, 8:24pm, Clint Adams wrote: > } Subject: requests > } > } Michal, how do you want ${param[(r)$anotherparam]} to behave, if not > } treating $anotherparam as a pattern? > > He wants expansion to behave as it would outside subscript [ ]; that > is, one must use $~param to get file globbing to happen, so he'd also > like that rule to apply within subscripts. It's fairly difficult, for > example, to match a literal "*" using subscription. Yes, that's exactly what I was expecting. > } 1. in ${param[(r)$anotherparam]} the result of $anotherparam > } is always treated as a pattern, it would be nice if one could use > } $~anotherparam for this. > > The "reason" for this behavior is that the stuff inside the [ ] is, > supposedly, parsed as if double-quoted. So in order to treat as a > pattern those strings that do NOT result from a parameter expansion, > the (r) has to imply the same sort of tokenization as $~anotherparam. > > E.g. in $param[(r)foo*$bar], foo* has to first be parsed as if quoted > (otherwise it'd be a file glob!) and then tokenized, so the same happens > to $bar. > > Internally, the expansion of $anotherparam is done independently of > the subscripting flag (r), which later tokenizes the fully-expanded > subscript. > > One can get the desired effect by using ${param[(r)${(q)anotherparam}]}, > but (another inconsistency) this works for arrays but fails for string > subscription on scalars. That's clearly a bug. So, do I understand correctly that changing (r) to behave as I'd like could be rather difficult for the expected benefits (especially as there is the (q) workaround (at least for arrays at the moment))? Anyway I'm not desperately in need of this feature. I just noticed that ${param#foo*$bar} treating the $bar differently than ${param[(r)foo*$bar]} is rather surprising for the casual user, independently of the lower level reasons for this, and I sent the report so that someday when zsh has all the possible features someone could fix this as well. > } 2. ${(B)param#pattern} > } gives 1 when there's no match -- could give 0 or 1+$#param like > } ${param[(i)pattern]} > } the same for (E) and {...%...} [...] > Probably it could be changed because nobody is using it; in fact, I'm > inclined to wonder what Michal is doing that caused him even to notice. Actually it was nothing I personally was doing. I was just looking for an answer to a usenet question, which was exactly how to find if and where one variable's text is contained in another. So for zsh (B) seemed like a simple and elegant solution, and it almost is. -- Michal Politowski -- mpol@lab.icm.edu.pl Warning: this is a memetically modified message