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.