ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kuiper, Arnout" <Arnout.Kui...@nl.origin-it.com>
Subject RE: Objections against advanced directory scanning
Date Wed, 02 Feb 2000 14:01:36 GMT
> 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