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 Williams Senior Software Engineer, Beran Instruments Ltd. Remove NOSPAM when replying, for timely response.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk