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

From: Anthony Williams (anthony.williamsNOSPAM_at_[hidden])
Date: 2003-04-25 05:38:30

Christian Engström   <christian.engstrom_at_[hidden]> writes:

> 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.

As there is the question of what to do with "foo.[ch]pp", and other similar
expressions. The syntax for wildcards depends on the system, so defining a
portable syntax that looks natural on all supported platforms is not generally
possible. On one filesystem I know "[abc]foo" is file foo in directory abc. On
Linux it is the three files afoo, bfoo and cfoo. 

> > 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.

IOW, you would allow path components to contain *any* character (as the
special characters for wildcards vary depending on the system) on the basis
that someone might want to add an extension to handle filenames containing
that character; only actual file operations would complain about the validity
of the path. I don't think this is a good plan.

Anthony
-- 
Anthony Williams
Senior Software Engineer, Beran Instruments Ltd.
Remove NOSPAM when replying, for timely response.