From: Beman Dawes (bdawes_at_[hidden])
Date: 2005-06-02 10:24:49
"Alisdair Meredith" <alisdair.meredith_at_[hidden]> wrote in message
> Beman Dawes wrote:
>> Question: what should path("foo//bar//").string() yield?
>> 1) "foo//bar//"
>> 2) "foo/bar/"
>> 3) "foo/bar/."
>> I'm leaning toward (2). Any comments?
> What happens if the user wants to start concatenating filenames on the
> end of the path? Ideally they will use library facilities of course
> <g> But if they insist on doing it the hard way, (2) 'just works', (3)
> requires additional parsing to remove the trailing '.' and (1) is still
> the oddball - for both good and ill.
> For me that makes it a call between (1) and (2), and I am in favour of
> (2) as I prefer to have a single, well defined portable representation
> - not something else I will need to parse again with yet another
> I think this means we are in agreement <g>
Good. I needed a reality check. I've got my nose so buried in the trees it
would be easy to miss the forest.
I guess the question comes down to this: In spite of POSIX specs and Windows
experiments to the contrary, are there ever valid paths with multiple
slashes (other than at the start)?
That may be the same issue as what to do for an operating system where slash
is valid and useful file or directory name. I think the example someone gave
was a filename like "data as of 1/2/2005".
A fix for both issues would be to introduce an escape sequence which means
"slash and I really mean it", or an escape path prefix which means "don't
modify this path in any way."
Both of those seem like ugly warts, and I've been avoiding them until
someone comes up with a compelling use case. I would hate to do something
ugly that may have no practical use whatsoever.
Hum... Gears clank in brain for awhile...
In the past, whenever I thought about escape sequences, I assumed we would
have to invent a new escape sequence, and that would be quite messy. But
what about hijacking one of the existing escape sequences?
Of all the C++ escape sequences, '\a' stands for BEL, and would seem to have
the least probability of ever being a valid character in a path. It isn't
valid at all for some OS's. If Boost.Filesystem hijacked it as an escape
sequence meaning ""slash and I really mean it", we could use option (2) with
all its advantages, yet if someone desperately needs more slashes for
whatever reason, they have a way of doing so.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk