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 <d.s_at_daniel.shahaf.name>
> > 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
Received on 2017-03-21 17:41:31 CET