search

commercialhaskell / path

Typed filepath
Other
122 stars 45 forks source link

Inconsistent "canonicalisation" on Linux vs Windows #153

Closed googleson78 closed 3 years ago

googleson78 commented 4 years ago

On linux:

> let Right x = parseRelFile "lol/kek"
> toFilePath x
"lol/kek"
> let Right x = parseRelFile "lol\\kek"
> toFilePath x
"lol\\kek"

The \\ in the second case is not converted to a /.

On windows (in cmd):

> let Right x = parseRelFile "lol/kek"
> toFilePath x
"lol\\kek"
> let Right x = parseRelFile "lol\\kek"
> toFilePath x
"lol\\kek"

The / in the first case is converted to a \.

Martinsos commented 3 years ago

@googleson78 , I am not contributor to Path but I have been dealing with it a lot recently, and I believe this is not a bug but a way how Path behaves. From the docs, what I got is that parseRelFile will parse the path using Posix separator (/) as a separator and whatever is current system separator. Resulting string will have separators as used by the system.

On Linux, system is Posix, so it will parse only on Posix separators, and result will have Posix separators, which is aligned with what you got there -> the reason why in second call you still have \ as separator is that parseRelFile actually treated it as a part of the file/dir name, not as a separator. And it treated it as part of the name because, as mentioned above, in this scenario it treats only Posix separators as separators.

In second case, on Win, system is Win, so it will parse both on Posix separators and Win separators (/), and result will be represented via Win separators. And that is visible from the example you provided.

googleson78 commented 3 years ago

Good point, I must have forgotten posix doesn't allow \ as a separator back then!