ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Petheram <pethe...@acm.org>
Subject Re: Objections against advanced directory scanning
Date Wed, 02 Feb 2000 15:35:19 GMT
Well I didn't realise that you weren't going to use regular expressions. If you
had said that initially then we could have saved a lot of e-mails.

'Regular Expressions are too difficult for ordinary users'. It seems to me that
you aren't expecting many Unix people to use ant.

'the '**' feature it is exaclty what most users find natural.'  Most ordinary
non Unix users you mean.

cheers

bill

"Kuiper, Arnout" wrote:

> > From: Bill Petheram [mailto:petheram@acm.org]
> > You are using a special syntax inside path specifications. In
> > my view you
> > should have path specification conforming to shell syntax
> > then apply a set
> > of regular expressions to each found lement from the path syntax.
>
> That's the whole point, it's not a path specification but a pattern.
> The patterns you specify in include & exclude are matched against
> paths. I call it a pattern, you call it a regexp, but we both mean
> the same thing.
>
> One of my first proposals used UNIX regexps for patterns, but I got a
> lot of complaints on that one, that it (regexps) was too difficult for
> the oridinary user. I agree on that one. Therefore I came up with
> a pattern (regexp if you like) that resembles the way it is done
> in UNIX, with wildcard expansion, except that I added one extra
> feature: '**'. Except for the '**' feature it is exaclty what most
> users find natural.
>
> In UNIX you can use: "ls -alF test/*/nr??/*.java" which lists all the
> java files in a directory called test, then any directory, then a directory
> starting with "nr" and then any two characters. This is exactly what
> I used for "my" patterns. Except that I added '**', which is an extension.
> You are not forced to use it (unless you want some special things done).
>
> Just see the patterns in the includes & excludes as a special kind of
> regexps instead of a path. That's how they are intended. (There are
> more kind of regexps than the one used in UNIX;-)
>
> > Maybe you haven't looked at ther approaches properly. tar,
> > find work OK.
>
> I looked at them, but again the regexps...
>
> > What about   path=test recurse=true ignore="\/CVS\/","~$","tmp$"
>
> What about it, besides that it uses UNIX regexps (for which was decided
> not to use them), this will ignore besides the intended
> "test/CVS/Repositories" and "test/foo/bar/CVS/Entries",
> also "test/CVS/foo/bar/test.java" which shouldn't be ignored. OK, this
> can be solved with "\/CVS\/[^\/]*$", but we cannot use regexps.
> BTW: this is a lot more complex than the "regexps"/patterns I propose now:
> "**/CVS/*" vs "\/CVS\/[^\/]*$".
>
> > Because there is not a clear separation between paths and regular
> > expressions.
>
> There is no separation, they are just patterns (or regexps if you like).
>
>   Cheers,
>
>     Arnout


Mime
View raw message