From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7980 invoked by alias); 3 Jan 2014 21:43:33 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 18273 Received: (qmail 139 invoked from network); 3 Jan 2014 21:43:27 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 From: Bart Schaefer Message-id: <140103134326.ZM11500@torch.brasslantern.com> Date: Fri, 03 Jan 2014 13:43:26 -0800 In-reply-to: <20140103201056.1bb2dc32@pws-pc.ntlworld.com> Comments: In reply to Peter Stephenson "Re: difference between ~ & ^ negation" (Jan 3, 8:10pm) References: <140101134459.ZM8931@torch.brasslantern.com> <20140102210147.0eca0601@pws-pc.ntlworld.com> <140102133636.ZM10014@torch.brasslantern.com> <140102233726.ZM10543@torch.brasslantern.com> <20140103194802.2f7cae9d@pws-pc.ntlworld.com> <20140103201056.1bb2dc32@pws-pc.ntlworld.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: Zsh Users Subject: Re: difference between ~ & ^ negation MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Jan 3, 8:10pm, Peter Stephenson wrote: } } Corrections I spotted myself before anyone else picks nits. Sadly, here come some nits anyway. } + For matching files by globbing, mytt(~) is the only globbing } + operator to have a lower precedence than mytt(/). In other words, } + when you have mytt(/a/path/to/match~/a/path/not/to/match) the mytt(~) } + considers what's before and what's after as complete paths to file names. In my first response on this thread, I struggled mightily with how to explain exactly how the before/after patterns are applied. The phrase "complete paths to file names" might be considered to mean that the paths must start from the root (which your example further suggests), but in fact they're not "complete" paths. For purposes of the pattern before the tilde, it matches ordinary path references which unless begun with a slash are relative to $PWD. For purposes of the pattern after the tilde, it matches strings, which merely happen to be [parts of] the names of things derived from the paths matched by the before part. } + You can put any other pattern characters in the expressions before and } + after the mytt(~), but note that the pattern after the tt(~) is really } + just a single pattern to match against every file found. This is what I mean ... it doesn't match against the *file* (so, e.g., qualifiers such as (@) or (/) don't matter) -- it matches against the *path name* of the file. } + If that's confusing, you can think of how mytt(~) works like this: } + take the pattern on the left, use it as normal to make a list of } + files, then for each file found see if it matches the pattern on the } + right and if it does take that file out of the list. Except thinking of it that way is misleading, because the other hard- to-grasp bit of this is that the after-pattern is matched against the name of each file AS IT IS FOUND by matching the before-pattern, *not* as a filter over the list of names after they are all found. That means that it's applied *before* any glob qualifiers including (e:...:) or (+...). } + if you're matching files by globbing note you can't put mytt(/)s } + inside the parentheses since the groups can't stretch across multiple } + directories. (You can do that, of course, whenever the character } + mytt(/) isn't special.) Which means you can only exclude multi-segment paths by using ~pat/tern at the very end of a glob. Another gotcha with the parenthesizing bit is that ^ is also a qualifier, so (^foo) at the end of glob is parsed as a qualifier unless you add more parens or have NO_BARE_GLOB_QUAL.