Re: [Boost-users] Re: interest in a glob_iterator?(directory_iterator with regex)

From: John Maddock (john_at_[hidden])
Date: 2004-01-16 06:46:19

> >   1. A function which translates glob patterns into regexes
> This is the non-trivial part.    I've opted to use a two-step process
> of:
>      - regex_traits to map shell-style meta chars to regex syntax
>                  where-ever there's a 1-1 mapping.
>      - a minimal string transform to convert the glob pattern to a
>                 regex pattern corresponding to the above traits.
> The specifics of this implementation are of course subject to debate.

Can't we do the whole thing with a regex search and replace? This has the
advantage that we don't need to instantiate a new basic_regex template
instance (so less code bloat if the user is already using regex).

I've been playing with this, and have attached a simple dos_wildcard
predicate that works this way - you can use this with
boost::filter_iterator_adapter right now, and should work for both portable
and native file paths (excluding one or two corner cases, like ":" in
RaiserFS file names, even this can probably be worked around).  How does
this compare to yours?

I admit I haven't tried with unix wildcards - although last time I looked at
the std, I admit I was surprised by how complex (and subtle) these are - let
me know if you want me to look for a unix-wildcard to regex transform.

> >
> >   2. A filter_iterator adaptor which uses a regex matching function
> >      to match the paths from a directory_iterator
> This is the easy part--provide a predicate which encapsulates and
>   invokes the regex produced above.

Yep,

typedef filter_iterator_adapter<directory_iterator,
some_kind_of_wildcard>::type wildcard_iterator;

would almost do the trick, however I would really like:

* The ability to combine predicates together in logical operations and
filter based on any predicate (the iterator should have the same type
irrespective of predicate type).  That way we can filter based on file time,
file type, file name or whatever.
* The abilty to search recursively if you want it (like unix find).
* The ability for recursive searches to "do the right thing" with links -
which is to say follow them, without getting into endless loops if the
directory structure is cyclic.
* The ability to expand shell-like wildcards, for example
~/boost/libs/*/build/*.mak

These might not all be the same iterator type of course :-)

John.