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

From: Simon Li (simon.li_at_[hidden])
Date: 2005-06-02 11:25:39

> From: boost-bounces_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Beman Dawes

> 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?

In the unlikely event that there is a filename with a BEL in it, is
there a way of "unescaping" the \a so that it isn't converted into a
slash?

If anyone's wondering about BEL being a valid filename character, I've
just done a quick test on Linux:

[0 simon_at_cstux test]$ mkdir `echo -e 'foo\abar'`
        # The stuff with echo ensures the argument passed to mkdir is a
BEL char
[0 simon_at_cstux test]$ ls
foo?bar
[0 simon_at_cstux test]$ ls | od -a
0000000   f   o   o bel   b   a   r  nl
0000010
        # od -e converts its raw input into ascii chars, or their
equivalent

Simon

This e-mail message (including its attachments) is private, is intended for the recipient named in it and may contain material which is confidential and privileged. 
No-one other than the named recipient may read, copy, rely on, redirect, save or alter the message or any part of it or any attachment to it in any way. 
VMS does not accept legal responsibility for the contents of this message.
Any views or opinions presented are solely those of the author and do not represent those of VMS unless otherwise specifically stated. 
While reasonable effort has been made to ensure this message is free of viruses, opening and using this message is at the risk of the recipient.