From: Christian Engström (christian.engstrom_at_[hidden])
Date: 2003-04-22 12:03:32
Beman Dawes wrote:
> At 08:22 AM 4/9/2003, Christian Engström wrote:
> >In my application I need to handle paths that contain wildcards, such as
> >for example "foo/chapter?.txt" or "bar/*/index.html".
> > ...
> I think that your need is both valid and commonplace, but that the way
> to handle it isn't necessarily to modify the filesystem library.
> Rather, think about using a filter iterator.
Yes, but that's exactly what I can't do because of the restriction in
Since I cannot use the original path "foo/chapter?.txt" to create a
filesystem iterator directly, I need to split it up into its components
"foo/" and "chapter?.txt", so that I can use "foo/" to construct a file
iterator, and "chapter?.txt" to create a filter that will select only
the files that I am interested in. The path member functions
"root_branch" and "leaf" would give me exactly what I need, but that is
of no help to me, since the wildcard character which is the reason why I
want to split it up in the first place, prevents me from creating the
path object that would let me do so.
There are other potential uses that might not involve any iterator at
all, such as using "complete" before echoing a path that the user has
just supplied. I think that this is a perfectly reasonable use of the
path class, but the implementation will not let me do it if the user
supplied path that contains any wildcard characters.
I see no reason why this should be prohibited by the class.
The only functionality that the path class really has, is to take a
string and chop it up into a sequence of strings, in the hope that each
such string represents a directory or a file on the underlying operating
system, but "[t]here is no guarantee that a path object represents a
path which is considered valid by the current operating system."
The path constructor still prohibits the use of some characters, for
The "/" character is needed for the syntax itself, so it may not be a
part of a filename, and the "\" and ":" characters are banned in order
to avoid confusion under Windows. This is perfectly reasonable.
The non-printing characters in the beginning of the ASCII code are
banned because they wouldn't really make sense and aren't being used by
any operating system that anybody has heard of, and the " character is
banned because its only possible use would be to allow quoted strings as
part of a path item, which neither Windows nor Unix users would want.
This too makes perfect sense to me.
This leaves us with the following characters that I cannot really see
any reason why they have to be banned:
< > | * ?
The implicitly stated reason for banning the characters <, >, and | is
that some (many) shells use them for piping, and although the argument
against them is strictly speaking not quite conclusive, I have no
problem with leaving them disallowed.
It is only with the * and ? characters that I think that the fact that
they are banned is harmful to the usefulness of the library, which is
why I submit that this be reconsidered.
After all, what is the point of having a file iterator that can only be
constructed from a path name that does not contain any wildcards? What,
exactly, is it supposed to iterate over?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk