Re: <n> == <n->?

[Johan Sundström <johsu650@xxxxxxxxxxxxxx>]

On Tue, 4 Apr 2000, Zefram wrote:

> I thought we'd decided, quite some time ago, that the numeric glob syntax
> was going to require a "-", to minimise ambiguity with redirection.

Sounds reasonable. After some digging through zshmisc(1), I'd guess the
situation we're trying to protect from a possible ambiguity is "< word" --
am I right? I may be at a loss here, but I don't quite see where the
problem might arise. Could someone depict an example or two and how to
trigger the problem?

I guess some situation with a directory having files named '1>', '1', '01'
and/or similar, and trying some command with an argument of <1> might be
what yo're getting at, but I haven't been able to figure out how or why.

> Actually, lex.c is more lenient than that.  Anything matching
> /\<[-0-9]+\>/ is initially lexed as a string rather than as operators.
> However, gettokstr() has some nasties here.  Although the above grammar
> applies at the beginning of a word, gettokstr() makes no such check
> in the middle of a word.  As far as it's concerned, anything matching
> /\<[-0-9]/ is the start of a glob operator, and it'll keep adding to
> the string (past whitespace and so on) until it finds the closing ">".
> Try typing "echo a<1" (and compare against "echo <1").

I noticed them being different (which showed better using cat than echo),
but I failed to understand how the first case tried to operate; to me, it
seemed like a broken effort at <<- or <<<, but then I guess I just didn't
understand what happened, so my guess isn't worth a lot. :-]

Either way, I'm not sure I see the impact of this on the case where the
word continues with a > and possibly more pattern matching. After all,
when I want redirection, I don't try my luck at inserting a < or > in
the middle of the current word I'm typing, and I haven't found anything in
the man pages supporting that behaviour either.

> "0#n" will do that (# = zero or more of the previous character).

As stated, I've been quite fond of <n>. Among other reasons, because
editing a past commandline from <n> to <-n> or <n-> was such a breeze. I'm 
familiar with #, but lazy as I am, I found the deprecated <n> syntax more 
typing friendly.

Another thing I forgot at first when on the subject: for quite some time
now, <x-y> has been ungreedy about its matches, to my disappointment. This
means that <1-2>* will match 1, 2, 10 through 29, and so on, instead of a
single, closed range, as at leas I would hope when constructing such a
pattern. The <x-y> syntax is of course still useful, but it takes a whole
lot more work and narrowing-down to make the pattern as tight as wanted.
Any chance of getting back the greedy version as seen in, for example,
3.0.0? (I'm starting to sound like an old fart, here... ;-) Some
pattern-matching token for stating the level of greediness would of course
be a welcome addition as well, but that sounds like a whole lot more work.

Oh, and don't get me wrong about all this; I'm not complaining about how
zsh works or doesn't work, I'm just trying to make the best I can of the
situation. Zsh isn't my all-time favourite shell without reason; I'm very
fond of zsh's trend of always trying to make things as handy as they can
be, and whenever I can help, I do my best.

/Johan Sundström, fond of globbing and pattern matching