[Mono-devel-list] Handling GetFullPath on Linux

[Jonathan Gilbert]

At 09:21 AM 22/11/2004 +0100, you wrote:
>Ben Maurer wrote:
>> Right now, there are two bugs about how Path.GetFullPath mangles paths
>> that are treated differently in Windows and Linux:
>> 
>> http://bugzilla.ximian.com/show_bug.cgi?id=53173
>> http://bugzilla.ximian.com/show_bug.cgi?id=68566
>> 
>> I think that the best way to go about fixing this is to check what
>> platform we are and change our parsing rules accordingly.
>> 
>> However, this may break the expectations of some users (especially
>> 68566). (for example, the user might expect a\b\c to get 
>> transformed to a/b/c on Linux, ie, they use it to change the path
>> components)
>
>This doesn't make sense. DirectorySeparatorChar and
>AltDirectorySeparatorChar should both be '/' on Linux. Applications that
>hardcode a backslash are lame.

That doesn't stop people from writing them.

>> I am not sure what to do about this. Which is more important, allowing
>> UNIX escapes, or keeping compat?
>
>Surely allowing UNIX escapes is more important?

Aren't escape codes the job of the shell? For instance, it is easy to
conceive of a shell which does not use '\' as the escape character. In
fact, I would find it hard to believe that none exist for which the escape
character is a configurable option. Note that escape codes are not used in
calls to open(). If Path.GetFullPath() returns a string with escape
characters in it, a FileStream cannot then open that file using the
resulting string.

If a user wants to write a program that displays the escaped path to a
file, let them make the assumption that the escape character is '\' and
escape the string themselves. It's not a particularly hard task; in my
mind, if a programmer cannot figure out how to write a function to escape
strings, they should probably learn more about programming before trying to
write a UNIX shell utility that cares so much about link names.

Is that too harsh??

Jonathan Gilbert