Twan van Laarhoven
twanvl at gmail.com
Sat Nov 3 15:48:12 EDT 2007
Bulat Ziganshin wrote:
> Hello Twan,
> Saturday, November 3, 2007, 8:56:33 PM, you wrote:
>>This seems wrong, as far as I know "C:File" is not a valid path. What is
>>the reason for this special case?
> it's correct path and i think that program has correct behavior in
> this case. if you need to construct "c:\file", you should use "c:\" as
> directory (written as "c:\\", of course)
On windows the 'path' "C:File" refers to the file named "File" on the
drive "C:", in the *current directory* for that drive. It is a kind of
half relative path.
This behaviour is at the very least unintuitive. In my opinion a 'path'
like "C:File" is completely useless. The FilePath library never produces
"C:" as an element itself, so what we do here doesn't matter much. A
good argument in favor of adding the backslash is that a trailing slash
on a directory name should not matter. I.e, for f not ending in a slash:
(f </> g) == (f ++ [pathSeparator] </> g)
This holds for normal directories, but not if f is a drive letter.
I have investigated what some different platforms do:
- Win32: PathAppend gives "C:\File"
- .Net: Path.Combine gives "C:File"
- Perl: File::Spec->catfile gives "C:/File"
I would take the behaviour of the Win32 api as authorative here.
More information about the Libraries