[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: wildcard authz docs question

From: Doug Robinson <doug.robinson_at_wandisco.com>
Date: Tue, 28 Mar 2017 19:39:14 -0400


On Tue, Mar 28, 2017 at 5:43 PM, Daniel Shahaf <d.s_at_daniel.shahaf.name>

> 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
and that awk/sed/perl/et. al. call them regular expressions. That said,
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
entry and for the purposes of matching act more like a file than a
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.




*T *925-396-1125
*E* doug.robinson_at_wandisco.com
*www.wandisco.com <http://www.wandisco.com/>*
Learn how WANdisco Fusion solves Hadoop data protection and scalability 
challenges <http://www.wandisco.com/hadoop/wd-fusion>
Listed on the London Stock Exchange: WAND 
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 
Received on 2017-03-29 01:39:21 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.