# ls -dl **/foodrwxr-xr-x 2 root root 4096 Mar 28 14:32 a/b/c/foo# ls -dl **/bar-rw-r--r-- 1 root root 0 Mar 28 14:32 a/b/c/bar# ls -dl **/bazlrwxrwxrwx 1 root root 10 Mar 28 14:36 a/b/c/baz -> a/b/c/biff
/*/*/** This requires 2 directories. It will match all directories 2 levels down - and then everything in all of the rest of those trees however deep. It should not, however, match a file or symlink in a directory, e.g. "/dirA/fileB". Whereas it will match "/dirA/dirB" along with "/dirA/dirB/fileC", etc.
/*/**/* This requires 1 directory and then something else. It will match "/dirA/fileB" or "/dirA/symlinkX" since "/**" can simply go to nothing. Or perhaps a different way to look at it is that "/**" can match "/" which, in its simplest will mean "/*/**/*" becomes "/*//*" and given that multiple '/' always collapse to a single '/' in "path arithmetic" becomes "/*/*" for its shortest match.
/**/*/* This requires 1 directory and then something else. Pretty much the same as the prior example and for the same reasons.
Doug Robinson wrote on Tue, Mar 21, 2017 at 11:40:50 -0400:
> The shell's all treat ** as * and require that it match something. So
> "mkdir -p foo/bar/baz" would match.
> No command shell that I know of (sh,bash,zsh,tcsh,csh,ksh) has a
> moral equivalent to "zero or more path components". Perl, python,
> et. al. do.
zsh interprets ** as meaning "zero or more path components" when it's
followed by a slash:
% mkdir -p foo/bar
% echo */**
% echo */**/
I looked up the Python and Perl equivalents, but the Python one has
a bug (the pattern '*/*/**' finds 'trunk/iota/' — with a trailing
slash — even if trunk/iota is a file) and I found no Perl equivalent in
its stdlib's File::Glob, so I couldn't compare against either of them.
> I would expect "/*/**/*", "/**/*/*" and "/*/*/**" to all match exactly the
> same sets of components.
Then our expectations are different as to what */*/** should mean. Can
you give an example of a tool where ./*/*/** matches ./trunk/iota when
iota is a file (not a directory)? As I said in my previous mail,
neither vim nor zsh — which, to clarify, both support a ** recursion
operaetor — match ./trunk/iota in that situation.
Thanks for jumping in.
> On Wed, Mar 15, 2017 at 5:55 AM, Daniel Shahaf <firstname.lastname@example.org>
> > From the 1.10 draft release notes:
> > > All wildcards apply to full path segments only, i.e. * never matches
> > > /, except for the case where /**/ matches zero or more path segments.
> > > For example, /*/**/* will match any path which contains at least
> > > 2 segments and is equivalent to /**/*/* as well as /*/*/**.
> > Are «/*/**/*» «/**/*/*» «/*/*/**» really equivalent? I would have
> > expected the first two to match any node except / and /'s immediate
> > children, but I wouldn't expect the third form to match /trunk/iota
> > where iota is a file, since the pattern has a trailing slash after the
> > non-optional second component.
> > Testing this in
> > cd $(mktemp -d)
> > mkdir -p foo/bar
> > , I see that neither vim nor zsh finds any matches for */*/**, meaning
> > they don't interpret ** as "zero or more" path components in this
> > pattern. I suppose they only treat ** in this way when it appears with
> > slashes immediately before and after it.
> > Cheers,
> > Daniel
Listed on the London Stock Exchange: WAND
THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE PRIVILEGED. If this message was misdirected, WANdisco, Inc. and its subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. If you are not the intended recipient, please notify us immediately and destroy the message without disclosing its contents to anyone. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. The views and opinions expressed in this e-mail message are the author's own and may not reflect the views and opinions of WANdisco, unless the author is authorized by WANdisco to express such views or opinions on its behalf. All email sent to or from this address is subject to electronic storage and review by WANdisco. Although WANdisco operates anti-virus programs, it does not accept responsibility for any damage whatsoever caused by viruses being passed.