* <..> ranges in globbing @ 1997-12-31 5:56 Geoff Wing 1997-12-31 6:17 ` Geoff Wing 1997-12-31 21:37 ` Wessel Dankers 0 siblings, 2 replies; 8+ messages in thread From: Geoff Wing @ 1997-12-31 5:56 UTC (permalink / raw) To: zsh-workers Heyla, % touch 101 111 121 % ls <10-12>1 ls: <10-12>1: No such file or directory Now, it's obvious why it's failing, since 101, 111 & 121 don't match the 10 to 12 range. My opinion is that it probably shouldn't fail in this case, but maybe a different operator or option/modifier should be used to get it to match. since there may be cases where someone wants to match on, say, ``<1-50>foo'' and not get, say, ``100foo'' matching. Opinions? -- Geoff Wing [gcw@pobox.com] Phone : +61-3-9818 2977 Technical Manager: PrimeNet Computer Consultants Facsimile: +61-3-9818 5155 Work URL: http://www.primenet.com.au/ Mobile : 0412 162 441 Ego URL: http://pobox.com/~gcw/ ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: <..> ranges in globbing 1997-12-31 5:56 <..> ranges in globbing Geoff Wing @ 1997-12-31 6:17 ` Geoff Wing 1998-01-12 11:13 ` PATCH: zsh 3.x: " Peter Stephenson 1997-12-31 21:37 ` Wessel Dankers 1 sibling, 1 reply; 8+ messages in thread From: Geoff Wing @ 1997-12-31 6:17 UTC (permalink / raw) To: zsh-workers Geoff Wing <mason@primenet.com.au> typed: :% touch 101 111 121 :% ls <10-12>1 :ls: <10-12>1: No such file or directory :Now, it's obvious why it's failing, since 101, 111 & 121 don't match the :10 to 12 range. My opinion is that it probably shouldn't fail in this case, :but maybe a different operator or option/modifier should be used to get it :to match. since there may be cases where someone wants to match on, say, :``<1-50>foo'' and not get, say, ``100foo'' matching. ``<1-50>*oo'' and ``100foo'' might be better examples. -- Geoff Wing [gcw@pobox.com] Phone : +61-3-9818 2977 Technical Manager: PrimeNet Computer Consultants Facsimile: +61-3-9818 5155 Work URL: http://www.primenet.com.au/ Mobile : 0412 162 441 Ego URL: http://pobox.com/~gcw/ ^ permalink raw reply [flat|nested] 8+ messages in thread
* PATCH: zsh 3.x: <..> ranges in globbing 1997-12-31 6:17 ` Geoff Wing @ 1998-01-12 11:13 ` Peter Stephenson 1998-01-12 16:16 ` Andrej Borsenkow 0 siblings, 1 reply; 8+ messages in thread From: Peter Stephenson @ 1998-01-12 11:13 UTC (permalink / raw) To: Zsh hackers list, zsh Geoff Wing wrote: > Geoff Wing <mason@primenet.com.au> typed: > :% touch 101 111 121 > :% ls <10-12>1 > :ls: <10-12>1: No such file or directory > :Now, it's obvious why it's failing, since 101, 111 & 121 don't match the > :10 to 12 range. My opinion is that it probably shouldn't fail in this case, > :but maybe a different operator or option/modifier should be used to get it > :to match. since there may be cases where someone wants to match on, say, > :``<1-50>foo'' and not get, say, ``100foo'' matching. > > ``<1-50>*oo'' and ``100foo'' might be better examples. This is the fix. This is entirely consistent with the way globbing usually works, I don't think a new operator is needed. If you want to make <1-50>*oo avoid matching 100foo, you will need <1-50>([^0-9]*|)oo (to be pedantic). I don't think it's fair to force <a-b> to consider only all the digits present, since it's not consistent with the usual pattern rule 'use as many characters as possible without causing the match to fail', even if it is the current behaviour. Is anyone sure that they rely on <1-50>*oo not matching 100foo? The old behaviour is tantamount to making * not match 0foo, which is counterintuitive. As far as I can remember I've always been careful to anchor the end of a numeric range for just this reason, not realising there was a bug. You should probably note that <100->0foo won't match 1000foo, since the 1000 gets swallowed up before the shell even knows it's going to have to match another digit next. This is a much more difficult problem requiring backtracking. I could make a special case so that simple things like this work, but expressions like <100->(0|bar)foo would require much more fiddling. (Of course, <100-999>0foo works now.) *** Src/glob.c.range Mon Jan 12 10:41:46 1998 --- Src/glob.c Mon Jan 12 10:41:57 1998 *************** *** 2265,2270 **** --- 2265,2271 ---- } else { /* Flag that there is no upper limit */ int not3 = 0; + char *opptr = pptr; /* * Form is <a-b>, where a or b are numbers or blank. * t1 = number supplied: must be positive, so use *************** *** 2284,2289 **** --- 2285,2299 ---- t3 = (unsigned long)zstrtol(ptr + 1, &pat, 10); DPUTS(*pat != Outang, "BUG: wrong internal range pattern"); pat++; + /* + * If the number found is too large for the pattern, + * try matching just the first part. This way + * we always get the longest possible match. + */ + while (!not3 && t1 > t3 && pptr > opptr+1) { + pptr--; + t1 /= 10; + } if (t1 < t2 || (!not3 && t1 > t3)) break; } -- Peter Stephenson <pws@ifh.de> Tel: +39 50 911239 WWW: http://www.ifh.de/~pws/ Gruppo Teorico, Dipartimento di Fisica Piazza Torricelli 2, 56100 Pisa, Italy ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: PATCH: zsh 3.x: <..> ranges in globbing 1998-01-12 11:13 ` PATCH: zsh 3.x: " Peter Stephenson @ 1998-01-12 16:16 ` Andrej Borsenkow 1998-01-12 16:59 ` Peter Stephenson 1998-01-12 17:10 ` Andrew Main 0 siblings, 2 replies; 8+ messages in thread From: Andrej Borsenkow @ 1998-01-12 16:16 UTC (permalink / raw) To: Peter Stephenson; +Cc: Zsh hackers list, zsh On Mon, 12 Jan 1998, Peter Stephenson wrote: > > You should probably note that <100->0foo won't match 1000foo, since > the 1000 gets swallowed up before the shell even knows it's going > to have to match another digit next. This is a much more difficult > problem requiring backtracking. I could make a special case so that > simple things like this work, but expressions like <100->(0|bar)foo would > require much more fiddling. (Of course, <100-999>0foo works now.) I am not sure, that it is right thing. The <m-n> can (always?) be rewritten using plain extended regular expression. In particular, <100-> is the same as [1-9][0-9][0-9]|[1-9][0-9]{3,} given file foo with 100foo 1000foo at my system I get egrep '([1-9][0-9][0-9]|[1-9][0-9]{3,})0foo' foo => 1000foo egrep '([1-9][0-9][0-9]|[1-9][0-9]{3,})foo' foo => 100foo 1000foo X/OPEN (and presumably POSIX and Unix 95) also require BRE and ERE to match the longest possible string - in case of 1000foo the longest possible is the whole word :-) Actually, what about replacing "ad hoc" code in ZSH by direct translation into normal regexp? It will probably be faster (who knows) and will give ZSH full power to support i18n - wich is currently not (portably) possible. I think, that <m-n> globbing is the only non-trivial part - all others are pretty sraightforward. ------------------------------------------------------------------------- Andrej Borsenkow Fax: +7 (095) 252 01 05 SNI ITS Moscow Tel: +7 (095) 252 13 88 NERV: borsenkow.msk E-Mail: borsenkow.msk@sni.de ------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: PATCH: zsh 3.x: <..> ranges in globbing 1998-01-12 16:16 ` Andrej Borsenkow @ 1998-01-12 16:59 ` Peter Stephenson 1998-01-12 17:10 ` Andrew Main 1 sibling, 0 replies; 8+ messages in thread From: Peter Stephenson @ 1998-01-12 16:59 UTC (permalink / raw) To: Zsh hackers list Andrej Borsenkow wrote: > On Mon, 12 Jan 1998, Peter Stephenson wrote: > > You should probably note that <100->0foo won't match 1000foo, since > > the 1000 gets swallowed up before the shell even knows it's going > > to have to match another digit next. This is a much more difficult > > problem requiring backtracking. I could make a special case so that > > simple things like this work, but expressions like <100->(0|bar)foo would > > require much more fiddling. (Of course, <100-999>0foo works now.) > > I am not sure, that it is right thing. No, it's definitely wrong if you think in ordinary pattern matching terms (and that's just what I suggested you should do for the patch I sent). It just seems too minor to fix at the moment. It could be done by implementing the range operator as a sort of closure using the new backtracking code. -- Peter Stephenson <pws@ifh.de> Tel: +39 50 911239 WWW: http://www.ifh.de/~pws/ Gruppo Teorico, Dipartimento di Fisica Piazza Torricelli 2, 56100 Pisa, Italy ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: PATCH: zsh 3.x: <..> ranges in globbing 1998-01-12 16:16 ` Andrej Borsenkow 1998-01-12 16:59 ` Peter Stephenson @ 1998-01-12 17:10 ` Andrew Main 1998-01-12 17:50 ` Andrej Borsenkow 1 sibling, 1 reply; 8+ messages in thread From: Andrew Main @ 1998-01-12 17:10 UTC (permalink / raw) To: borsenkow.msk; +Cc: pws, zsh-workers, zsh Andrej Borsenkow wrote: >I am not sure, that it is right thing. The <m-n> can (always?) be >rewritten using plain extended regular expression. Yes, we should always handle it properly, as if this were done. >Actually, what about replacing "ad hoc" code in ZSH by direct translation >into normal regexp? It will probably be faster (who knows) I suspect that it will make little performance difference in the majority of cases. It would, however, cause serious portability problems, if we tried to use the system's regexp library. Many regexp libraries don't actually have the power of zsh glob patterns for patten matching, to say nothing of **/. and will give >ZSH full power to support i18n In what respect? -zefram ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: PATCH: zsh 3.x: <..> ranges in globbing 1998-01-12 17:10 ` Andrew Main @ 1998-01-12 17:50 ` Andrej Borsenkow 0 siblings, 0 replies; 8+ messages in thread From: Andrej Borsenkow @ 1998-01-12 17:50 UTC (permalink / raw) To: Andrew Main; +Cc: pws, zsh-workers, zsh On Mon, 12 Jan 1998, Andrew Main wrote: > > and will give > >ZSH full power to support i18n > > In what respect? > [:class:] [=a=] [.a.] [a-b] It is impossible to portably implement them, because they require information about current locale, which just is not available at user level. ------------------------------------------------------------------------- Andrej Borsenkow Fax: +7 (095) 252 01 05 SNI ITS Moscow Tel: +7 (095) 252 13 88 NERV: borsenkow.msk E-Mail: borsenkow.msk@sni.de ------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: <..> ranges in globbing 1997-12-31 5:56 <..> ranges in globbing Geoff Wing 1997-12-31 6:17 ` Geoff Wing @ 1997-12-31 21:37 ` Wessel Dankers 1 sibling, 0 replies; 8+ messages in thread From: Wessel Dankers @ 1997-12-31 21:37 UTC (permalink / raw) To: Geoff Wing; +Cc: zsh-workers On 31 Dec 1997, Geoff Wing wrote: > Heyla, > % touch 101 111 121 > % ls <10-12>1 > ls: <10-12>1: No such file or directory > Now, it's obvious why it's failing, since 101, 111 & 121 don't match the > 10 to 12 range. My opinion is that it probably shouldn't fail in this case, Indeed. Any glob experts around? > but maybe a different operator or option/modifier should be used to get it > to match. since there may be cases where someone wants to match on, say, > ``<1-50>foo'' and not get, say, ``100foo'' matching. <1-50>foo would never match 100foo, even with the behaviour described above. Even though "<1-50>" could expand to `10', it still leaves an unexplained `0'. "<1-50>foo" != "<1-50>0foo", so there is no need for an extra operator. -- Wessel Dankers ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~1998-01-12 17:56 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1997-12-31 5:56 <..> ranges in globbing Geoff Wing 1997-12-31 6:17 ` Geoff Wing 1998-01-12 11:13 ` PATCH: zsh 3.x: " Peter Stephenson 1998-01-12 16:16 ` Andrej Borsenkow 1998-01-12 16:59 ` Peter Stephenson 1998-01-12 17:10 ` Andrew Main 1998-01-12 17:50 ` Andrej Borsenkow 1997-12-31 21:37 ` Wessel Dankers
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).