<..> ranges in globbing

<..> ranges in globbing

[Geoff Wing]

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/

Re: <..> ranges in globbing

[Geoff Wing]

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/

Re: <..> ranges in globbing

[Wessel Dankers]

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

PATCH: zsh 3.x: <..> ranges in globbing

[Peter Stephenson]

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

Re: PATCH: zsh 3.x: <..> ranges in globbing

[Andrej Borsenkow]

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
-------------------------------------------------------------------------

Re: PATCH: zsh 3.x: <..> ranges in globbing

[Peter Stephenson]

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

Re: PATCH: zsh 3.x: <..> ranges in globbing

[Andrew Main]

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

Re: PATCH: zsh 3.x: <..> ranges in globbing

[Andrej Borsenkow]

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
-------------------------------------------------------------------------