[boost] Re: Questions on wildcarding boost::filesystem

From: Christian Engström (christian.engstrom_at_[hidden])
Date: 2003-04-25 04:30:30

Daryle Walker wrote:
> 
> 1.    Aren't wild-cards in filenames/paths resolved by the shell?  Don't 
> the filesystem routines only see the names _after_ expansion?  If the 
> shell handles wild-cards, is it appropriate for boost::filesystem to 
> deal with them at all?

The Windows shell does not expand wildcards before it passes the command 
line parameters to the program.  Most Unix shells do -- if you let them, 
that is, if you do not put the command line parameter within single 
quotes.  But this of course only applies to file names that were passed 
to the program via the command line.  If a program has gotten hold of a 
path like "foo/*.txt" by some other means, there is still a question of 
what it should do with it.

> 
> 2.    If we decide for boost::filesystem wild-carding, then would it 
> defer to OS routines for expansion?  Or would we have to carry copies of 
> all the expansion rules (for Windows, UNIX, etc.)?

Good question, and one that will no doubt spur extended discussions if 
that decision is taken, but that is not wat I was proposing in my 
earlier post.

What I was asking for was simply that the filesystem::path class should 
accept the characters as such, so that anyone who is interested in 
developing a wildcard expansion system, whether for his own personal use 
or for submission to Boost, can use the path class in the implementation.

The path class as it stands right now contains several features that 
would be absolutely perfect for anyone who had this ambition, but at the 
moment it cannot be used for this purpose, because the path constructor 
bans the use of the "*" and "?" characters altogether from generic paths.

There is no reason that I can think why the path class has to do this, 
but as long as it does, anyone who is interested in handling paths with 
wildcards in any way whatsoever will have to develop his own path class 
instead of using the one supplied by Boost.

> 
> 3.    Wouldn't we need a way to turn off or escape wild-carding, if an 
> user gives a path with wild-cards characters that should _not_ be 
> expanded?  (Remember that '*' and '?' are legitimate filename characters 
> on some systems.)

Not necessarily, unless one really wanted.  The underlying motive behind 
the prohibition of "*" and "?" is that the designers of the filesystem 
library feel that nobody should use those characters as part of a 
filename, even if the underlying operating system considers them 
legitimate.  This restriction is explicitly mentioned in the 
documentation, and is something I agree completely with.  After all, how 
many people in the real world would be interested in adopting a file 
naming practice that will effectively ensure that their programs can 
never be ported to either Windows or Unix/Linux without loads of hassle?

The problem with boost::filesystem as it stands now, in my opinion, is 
that the restriction is being enforced in the wrong place.  If it was 
being done in fstream it would be a sensible and useful feature; now 
that it is being done in path, it just prevents anyone from even trying 
to add any wildcard handling capabilities to filesystem.