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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk