From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9506 invoked from network); 4 Apr 2000 17:01:27 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 4 Apr 2000 17:01:27 -0000 Received: (qmail 4508 invoked by alias); 4 Apr 2000 17:00:51 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 10475 Received: (qmail 4458 invoked from network); 4 Apr 2000 17:00:46 -0000 Date: Tue, 4 Apr 2000 19:00:42 +0200 (MET DST) From: =?ISO-8859-1?Q?Johan_Sundstr=F6m?= X-Sender: johsu650@astmatix.ida.liu.se To: zsh-workers@sunsite.auc.dk Subject: Re: == ? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE 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 (# =3D zero or more of the previous character). As stated, I've been quite fond of . Among other reasons, because editing a past commandline from to <-n> or was such a breeze. I'm= =20 familiar with #, but lazy as I am, I found the deprecated syntax more= =20 typing friendly. Another thing I forgot at first when on the subject: for quite some time now, 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 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=F6m, fond of globbing and pattern matching