[boost] Re: [filesystem] Generic path grammar corner cases

From: Beman Dawes (bdawes_at_[hidden])
Date: 2005-06-02 10:24:49

"Alisdair Meredith" <alisdair.meredith_at_[hidden]> wrote in message 
news:d7n3g2$1h8$1_at_sea.gmane.org...
> 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
> library.
>
> 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.

Thoughts?

--Beman