[boost] Re: Oughtn't filesystem::path acc ept the "*" and "?" wildcards?

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 
filesystem::path.

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

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?