Re: wildcard authz docs question

[Doug Robinson]

Daniel:

On Tue, Mar 28, 2017 at 5:43 PM, Daniel Shahaf 
wrote:

> Doug Robinson wrote on Tue, Mar 28, 2017 at 09:05:53 -0400:
> > That said, in discussions I've had I think about the SVN regex "**"
> > differently than the zsh construct.  The way that I interpret "/**" is
> > "everything below and including slash" - so "**" is the moral equivalent
> of
> > Perl's ".*" wildcard.  It need not be followed by any terminal pattern to
> > match anything - since it matches them all.  If it was followed by
> > something then that something would be required.
> >
>
> Note that your terminology is backwards: "**" is a wildcard and ".*" is
> a regex.
>

Agreed - sort of.

I've been using them interchangeably: the  longer you use them the more that
you come to consider them the same.  I know that the shell calls them
wildcards
and that awk/sed/perl/et. al. call them regular expressions.  That said,
they're
doing the same thing in different contexts.

> So let me break the 3 patterns down:
> >
> > /*/*/**   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.
>
> That's an interesting one.  Neither vim nor zsh matches dirA/dirB here —
> they only match dirents _under_ it — but it's certainly defensible to
> match it, exactly as you say.
>
> To clarify, if foo/bar is a symlink then it is not a directory, no
> matter what its target is and what else exists in the repository.  (In
> particular, if its target is "baz" and foo/baz/ exists, foo/bar is still
> not a directory.)
>

Agreed: symlinks are their own form of fun given their semantics on
various system calls.  But in the end they are just another type of
directory
entry and for the purposes of matching act more like a file than a
directory.
And I very much agree that it does not matter what they are pointing at.


> So, for example, [foo/bar/**] would apply to foo/bar/, iff it exists and
> is a directory.  That sounds good.
>
> > /*/**/*   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.
>
> Agreed.
>
> > /**/*/*   This requires 1 directory and then something else.  Pretty much
> > the same as the prior example and for the same reasons.
>
> Agreed.
>

Excellent!

Cheers!

Doug
-- 
*DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER

*T *925-396-1125
*E* doug.robin...@wandisco.com

*www.wandisco.com *

-- 


Learn how WANdisco Fusion solves Hadoop data protection and scalability 
challenges 

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.

Re: wildcard authz docs question

[Daniel Shahaf]

Doug Robinson wrote on Tue, Mar 28, 2017 at 09:05:53 -0400:
> Daniel:
> 
> Sorry for the delay - I missed the post.

No worries.

> That said, in discussions I've had I think about the SVN regex "**"
> differently than the zsh construct.  The way that I interpret "/**" is
> "everything below and including slash" - so "**" is the moral equivalent of
> Perl's ".*" wildcard.  It need not be followed by any terminal pattern to
> match anything - since it matches them all.  If it was followed by
> something then that something would be required.
> 

Note that your terminology is backwards: "**" is a wildcard and ".*" is
a regex.

> So let me break the 3 patterns down:
> 
> /*/*/**   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.

That's an interesting one.  Neither vim nor zsh matches dirA/dirB here —
they only match dirents _under_ it — but it's certainly defensible to
match it, exactly as you say.

To clarify, if foo/bar is a symlink then it is not a directory, no
matter what its target is and what else exists in the repository.  (In
particular, if its target is "baz" and foo/baz/ exists, foo/bar is still
not a directory.)

So, for example, [foo/bar/**] would apply to foo/bar/, iff it exists and
is a directory.  That sounds good.

> /*/**/*   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.

Agreed.

> /**/*/*   This requires 1 directory and then something else.  Pretty much
> the same as the prior example and for the same reasons.

Agreed.

Thanks,

Daniel

Re: wildcard authz docs question

[Doug Robinson]

Daniel:

Sorry for the delay - I missed the post.

And, I'm going to recant my original conclusion - my apologies for not
treating this with sufficient vigor the 1st time around.

Wow - it's been a long time since I played with zsh.  Yep, I see the
reference to "‘***/*’ is equivalent to ‘*(*/)#*’".  So, playing with this,
the zsh man page is a bit loose with the term "file" where they are really
talking about a "directory entry":

# ls -dl **/foo
drwxr-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 **/baz
lrwxrwxrwx 1 root root 10 Mar 28 14:36 a/b/c/baz -> a/b/c/biff


That said, in discussions I've had I think about the SVN regex "**"
differently than the zsh construct.  The way that I interpret "/**" is
"everything below and including slash" - so "**" is the moral equivalent of
Perl's ".*" wildcard.  It need not be followed by any terminal pattern to
match anything - since it matches them all.  If it was followed by
something then that something would be required.

So let me break the 3 patterns down:

/*/*/**   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.


Is this more along the lines of what you were thinking?

Thank you.

Doug


On Tue, Mar 21, 2017 at 12:36 PM, Daniel Shahaf 
wrote:

> Doug Robinson wrote on Tue, Mar 21, 2017 at 11:40:50 -0400:
> > Daniel:
> >
> > 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 */**
> foo/bar
> % echo */**/
> foo/ foo/bar/
>
> 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.
>
> Cheers,
>
> Daniel
>
>
> > Cheers,
> >
> > Doug
> >
> > On Wed, Mar 15, 2017 at 5:55 AM, Daniel Shahaf 
> > wrote:
> >
> > > 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
>



-- 
*DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER

*T *925-396-1125
*E* doug.robin...@wandisco.com

*www.wandisco.com *

-- 


Learn how WANdisco Fusion solves Hadoop data protection and scalability 
challenges 

Listed on the London Stock Exchange: WAND 


THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL