Path: utzoo!telly!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!usc!cs.utexas.edu!uunet!zephyr!tektronix!tekcrl!tekfdi!videovax!bart From: bart@videovax.tv.Tek.com (Bart Massey) Newsgroups: gnu.bash.bug Subject: Re: File Name Globbing Message-ID: <5483@videovax.tv.Tek.com> Date: 18 Jul 89 18:30:36 GMT References: <8907160207.AA22322@comp.vuw.ac.nz> <8907170737.AA04585@aurel.caltech.edu> Reply-To: bart@videovax.tv.tek.com (Bart Massey) Distribution: gnu Organization: Tektronix TV Measurement Systems, Beaverton OR Lines: 25 In article <8907170737.AA04585@aurel.caltech.edu> bfox@aurel.caltech.edu.date.sun, 16 Jul 89 14:05:56 +1200 From: Ray Nickson writes: > > 2) You say the reason that you didn't expand the first word is because > you know of a command that contains a globbing character. Well, this > is a much better argument for Bourne shell behaviour than any other I > have thought of, since the first word of a command is not the only > place you will see a globbing character. In the "if" command is > another place. As the second word in an "eval" command is another > place. Agreed. However, the earlier poster's suggestion that invalid globs not expand should fix the problem. E.g. '[a-z' is a literal string, but '[a-z]' is a regexp. Note that all such "invalid" cases must involve the characters '[' or ']', since this is the only Bourne Shell globbing syntax which uses more than one character. Since '[' (a.k.a. 'set') is the only command I can think of or find on my machine which even potentially causes globbing problems, IMHO the above semantic should be more than adequate... I have a piece of really slow, recursive match, Bourne Shell style globbing code I wrote myself in C which implements the above semantic -- you're welcome to it if you're interested. Bart Massey ..tektronix!videovax.tv.tek.com!bart ..tektronix!reed.bitnet!bart