"Jonathan Wakely" <cow@compsoc.man.ac.uk> wrote in message news:20050602175118.GA34709@compsoc.man.ac.uk...
On Thu, Jun 02, 2005 at 10:37:14AM -0400, Beman Dawes wrote:
"David Daeschler" <daveregs@rsaisp.com> wrote in message news:d7n1to$rr7$1@sea.gmane.org...
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.
I don't believe removing a trailing slash is a good idea because that isn't how POSIX or Windows treats a trailing slash, and also because some apps may depend on it to distinguish between a directory path and a file path.
e.g a trailing slash changes semantics when dealing with symlinks:
$ mkdir aaa $ touch aaa/monkey $ ln -s aaa bbb $ ls -l bbb lrwxrwxrwx 1 redi redi 3 Jun 2 18:40 bbb -> aaa $ ls -l bbb/ -rw-rw-r-- 1 redi redi 0 Jun 2 18:40 monkey
Interesting.
In answer to your first question, I think I prefer (2) too.
Regarding the escape sequence, do you want to play nicely with null-terminated char strings? If not, '\0' would be my choice, since that and '/' are the only characters POSIX disallows in a filename. But there are probably plenty of ways that would cause otherwise valid programs to fail.
Yep, I thought of that too. But since we do want to be able to "play nicely with null-terminated char strings", I think it's a non-starter.
Then again, I'm not sure it's necessary to support slashes in filenames at all.
I don't think it is strictly necessary for the Boost implementation, either. But I want to propose Boost.Filesystem for standardization, and need to know what the spec would be for, say OpenVMS. And allowing them does cover the admittedly obscure case of someone who just has to create a path "foo//bar", which they would do via path("foo/\abar"). It is a bit of a kludge, but since the expected usage is very uncommon, I don't see that as a problem. The impact on both specification and implementation is trivial. Thanks, --Beman