From: David Daeschler (daveregs_at_[hidden])
Date: 2005-06-02 08:37:53
Since the slash or slashes in that case are extraneous, I would also say
option 2 is the way to go. Remove the trailing slash because it was
probably not intended in the first place.
The only question I would have is about the path that is simply "//" or
natively in the windows world "\\". In the windows command prompt changing
to those two directories yields the following results.
C:\Documents and Settings\blah>cd \\
'\\'
CMD does not support UNC paths as current directories.
and
C:\Documents and Settings\blah>cd \
C:\>
So if you were to trim the trailing slash in "//", it could potentially have
different results in windows since it sees the "\\" as the beginning of a
UNC path.
Or I could just be looking to far into it, and this isn't a problem at all?
- Dave
"Beman Dawes" <bdawes_at_[hidden]> wrote in message
news:d7mvgn$jnu$1_at_sea.gmane.org...
> I'm working to align the Boost.Filesystem generic path grammar with the
> POSIX specification. Doing so clarifies the specification of the library,
> and ensures that all native paths for both POSIX and Windows will work
> correctly. (Windows follows the POSIX conventions in some of the corner
> cases involved.)
>
> The particular cases involve extra slashes in paths. For example,
> "/foo//bar//". I was surprised to find that such a path is well-defined
> for POSIX and Windows, with a meaning of "/foo/bar/." In other words,
> multiple slashes treated as a single slash, and paths with a trailing
> slash treated as if a period was appended. The rules for more than two
> leading slashes are a bit more complex - for POSIX they are treated as a
> single slash, for Windows that is an invalid path.
>
> Question: what should path("foo//bar//").string() yield?
>
> 1) "foo//bar//"
> 2) "foo/bar/"
> 3) "foo/bar/."
>
> (1) follows the rule that the path string is always exactly as input.
> Desirable in that if a platform actually implements something a bit
> different from the POSIX specs for multiple slashes, implementations will
> behave as expected for the platform. Downside is much more complex
> implementation (because many more functions have to be able to cope with
> multiple slashes) and more complex testing.
>
> (2) Desirable in that if a platform actually implements something a bit
> different from the POSIX (and Windows) specs for multiple slashes,
> implementations will behave portably and correctly in a POSIX (and
> Windows) sense.
>
> (3) Desirable in that for all three options directory iteration will
> return three elements - "foo", "bar", "." - so it is a bit counter
> intuitive for the "." not to appear in the string() results. Not a strong
> argument.
>
> I'm leaning toward (2). Any comments?
>
> --Beman
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://listarchives.boost.org/mailman/listinfo.cgi/boost
>