[Mono-devel-list] Handling GetFullPath on Linux
2a5gjx302 at sneakemail.com
Mon Nov 22 03:48:46 EST 2004
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:
>> 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
>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
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??
More information about the Mono-devel-list