From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6415 invoked from network); 3 Sep 1999 04:35:26 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 3 Sep 1999 04:35:26 -0000 Received: (qmail 5128 invoked by alias); 3 Sep 1999 04:35:08 -0000 Mailing-List: contact zsh-users-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 2555 Received: (qmail 5120 invoked from network); 3 Sep 1999 04:35:04 -0000 From: "Bart Schaefer" Message-Id: <990903043451.ZM25090@candle.brasslantern.com> Date: Fri, 3 Sep 1999 04:34:51 +0000 In-Reply-To: <19990903024039.A23433@thelonious.new.ox.ac.uk> Comments: In reply to Adam Spiers "Re: strange glob expansion" (Sep 3, 2:40am) References: <19990901101116.A8076@youkaidi.irisa.fr> <990901174608.ZM19896@candle.brasslantern.com> <19990903024039.A23433@thelonious.new.ox.ac.uk> X-Mailer: Z-Mail (5.0.0 30July97) To: Adam Spiers , zsh-users@sunsite.auc.dk Subject: Re: strange glob expansion MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Sep 3, 2:40am, Adam Spiers wrote: } Subject: Re: strange glob expansion } } Bart Schaefer (schaefer@candle.brasslantern.com) wrote: } > Directory separators can't be used inside parentheses. Parenthesized } > patterns match within one level of file hierarchy only. } } On a related topic, the following puzzles me: } } % echo L(*/) } zsh: no matches found: L(*/) (why doesn't this match the 2 dirs?) You've just encountered one of the minor oddities of zsh "glob qualifiers". At the end of a glob pattern, anything in parentheses is taken to be a glob qualifier; the qualifier (*/) would mean "match a file that is both a plain executable file and a directory" which is obviously impossible. However, "L" is not a glob pattern! A glob pattern must contain one of *, ?, [], or a parenthesized pattern. So in that example, (*/) is not a glob qualifier at all, it is instead a parenthesized pattern that matches any series of characters followed by a '/' character. Directory separators can't be used inside parentheses (he says again), so that pattern can't match any files no matter how you look at it. (This actually seems to be different in 3.1.6 -- that is, the trailing parens are taken as a qualifier even if there are no "magic" characters to the left of them. I don't recall if this is intentional or not.) } % echo L(*/)# } LWP LWP.pm Lingua (why does this match a file?) This is probably a bug. That pattern should mean "L followed by any number of repetitions of any string of characters followed by a slash" (when you have extendedglob set), which obviously shouldn't match anything either. Peter's latest patches to 3.1.6 (zsh-workers 7611 and 7624) cause zsh to complain: zagzig<8> echo L(*/)# zsh: bad pattern: L(*/)# Zsh is being very clever here, as it's only a bad pattern in file-globbing context, not in string matching context: zagzig<9> [[ Lazy//lob/ == L(*/)# ]] && echo ok ok } % echo L(*/)z } LWP LWP.pm Lingua (HUH?) That is probably the same bug as L(*/)#. Zsh is discarding everything from the '/' onward, because it gets confused by the directory separator inside the parens, and then matches against L(*). } The upshot of this is that to match all Perl modules starting with `L' } below the cwd, I have to use L{*/**/*,}.pm instead of L**/*.pm. What? L{*/**/*,}.pm is first brace-expanded to L*/**/*.pm and L.pm, and then globbed. There probably isn't an L.pm, so that matches in any sub- directory whose name starts with L and all its subdirectories, all the files whose names end with .pm. You could have done that without the braces, with L*/**/*.pm, but I suspect what you meant was */**/L*.pm. You never want ** anywhere except at the beginning of a pattern or in between a pair of slashes. Anywhere else it means exactly the same thing as a single *. } P.P.S. What version would you rather have patches against? 3.1.6 } clean? The latest pws? The latest thing you can manage to patch against. The more patches from other people you can keep up with, the better. If you can't get them all, identify the base version against which you are patching (where any of the pws-X releases counts as a "base") and give the article numbers of any other patches you have applied and upon which yours may depend. PWS is pretty good at figuring it out from there. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com