* requests @ 2001-04-15 0:24 Clint Adams 2001-04-16 16:06 ` (Fwd) requests Bart Schaefer [not found] ` <1010415032859.ZM27364@candle.brasslantern.com> 0 siblings, 2 replies; 5+ messages in thread From: Clint Adams @ 2001-04-15 0:24 UTC (permalink / raw) To: zsh-workers; +Cc: mpol, 92780-forwarded For the complaint department. Michal, how do you want ${param[(r)$anotherparam]} to behave, if not treating $anotherparam as a pattern? ----- Forwarded message from Michal Politowski <mpol@charybda.icm.edu.pl> ----- Actually I can't tell if these are (mis)features or bugs, but I don't like them so here comes the report. In decreasing order of annoyance. 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. 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 {...%...} 3. ${param[(i)pattern]} behaves differently for scalars and for arrays when there is no match. For scalars returns 0, for arrays the index of last element + 1. -- System Information Debian Release: testing/unstable Architecture: i386 Kernel: Linux Amber 2.2.19 #1 Thu Mar 29 15:52:51 CEST 2001 i586 Versions of packages zsh depends on: ii libc6 2.2.2-4 GNU C Library: Shared libraries an ii libncurses5 5.2.20010318-1 Shared libraries for terminal hand -- Michal Politowski -- mpol@lab.icm.edu.pl Warning: this is a memetically modified message ^ permalink raw reply [flat|nested] 5+ messages in thread
* (Fwd) Re: requests 2001-04-15 0:24 requests Clint Adams @ 2001-04-16 16:06 ` Bart Schaefer 2001-04-16 17:29 ` requests Bart Schaefer [not found] ` <1010415032859.ZM27364@candle.brasslantern.com> 1 sibling, 1 reply; 5+ messages in thread From: Bart Schaefer @ 2001-04-16 16:06 UTC (permalink / raw) To: zsh-workers My apologies if this ends up appearing twice -- I sent it Saturday night but it still hasn't come through the archives. In the interim since the text below was written, I've posted a patch that includes a fix for the #3 bug. --- Forwarded mail from <schaefer@candle.brasslantern.com> ("Bart Schaefer") From: "Bart Schaefer" <schaefer@candle.brasslantern.com> Date: Sun, 15 Apr 2001 03:28:58 +0000 To: zsh-workers@sunsite.dk Subject: Re: requests Cc: 92780-forwarded@bugs.debian.org, mpol@charybda.icm.edu.pl The timing of this is interesting, as I've just spent the entire day fooling with SourceForge bug #104052 (without making much headway). 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. } 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. } 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 {...%...} This is a known inconsistency (there's even a comment about it in the Tests/*parameter.ztst file). It's been left unchanged for backwards compatibility, though it's not clear whether its use is widespread enough that it would cause an outcry were it changed. 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. } 3. ${param[(i)pattern]} behaves differently for scalars and for arrays } when there is no match. For scalars returns 0, for arrays the index of } last element + 1. I think that one's just an implementation oversight; both forward and reverse subscripting of scalars fall through to the same return value when the pattern isn't found. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net ---End of forwarded mail from <schaefer@candle.brasslantern.com> ("Bart Schaefer") -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: requests 2001-04-16 16:06 ` (Fwd) requests Bart Schaefer @ 2001-04-16 17:29 ` Bart Schaefer 0 siblings, 0 replies; 5+ messages in thread From: Bart Schaefer @ 2001-04-16 17:29 UTC (permalink / raw) To: zsh-workers On Apr 16, 4:06pm, Bart Schaefer wrote: } Subject: (Fwd) Re: requests } } } 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. } } 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. I have a fix for that now, too. It failed only when the `*' was the last character in $anotherparam, because the code that checked for whether to append a `*' to the pattern failed to check that the next-to-last character might be a backslash. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <1010415032859.ZM27364@candle.brasslantern.com>]
* Re: requests [not found] ` <1010415032859.ZM27364@candle.brasslantern.com> @ 2001-04-19 15:00 ` Michal Politowski 2001-04-20 3:04 ` requests Bart Schaefer 0 siblings, 1 reply; 5+ messages in thread From: Michal Politowski @ 2001-04-19 15:00 UTC (permalink / raw) To: zsh-workers; +Cc: 92780, Bart Schaefer On Sun, 15 Apr 2001 03:28:58 +0000, Bart Schaefer <schaefer@candle.brasslantern.com> 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: requests 2001-04-19 15:00 ` requests Michal Politowski @ 2001-04-20 3:04 ` Bart Schaefer 0 siblings, 0 replies; 5+ messages in thread From: Bart Schaefer @ 2001-04-20 3:04 UTC (permalink / raw) To: Michal Politowski, zsh-workers On Apr 19, 5:00pm, Michal Politowski wrote: } Subject: Re: requests } } 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))? Yes, you understand correctly. And I later discovered (in the course of fixing it) that the problem with $scalar[(r)${(q)pattern}] occurs only if $pattern ends with a `*'. } ${param#foo*$bar} treating the $bar differently than } ${param[(r)foo*$bar]} is rather surprising for the casual user If that's the only thing about zsh that surprises a casual user, we're in better shape than I thought. :-) -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2001-04-20 7:22 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-04-15 0:24 requests Clint Adams 2001-04-16 16:06 ` (Fwd) requests Bart Schaefer 2001-04-16 17:29 ` requests Bart Schaefer [not found] ` <1010415032859.ZM27364@candle.brasslantern.com> 2001-04-19 15:00 ` requests Michal Politowski 2001-04-20 3:04 ` requests Bart Schaefer
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).