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. Twan

I find it esthetically displeasing, but Bulat is correct; it is relied on in many situations by many programs. -----Original Message----- From: libraries-bounces@haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Bulat Ziganshin Sent: Saturday, November 03, 2007 4:22 PM To: Twan van Laarhoven Cc: libraries@haskell.org; Bulat Ziganshin Subject: Re[2]: System.FilePath.joinDrive problem Hello Twan, Saturday, November 3, 2007, 10:48:12 PM, you wrote:

This behaviour is at the very least unintuitive.

it was in dos for 23 years, so it is well known and used by all utilities: D:\temp\8> c: C:\Haskell\docs> dir d: Contents of directory D:\temp\8 31.10.2007 12:41 <DIR> . 31.10.2007 12:41 <DIR> .. 30.10.2007 23:58 <DIR> 1 15.04.2005 19:31 24 compile.btm C:\Haskell\docs> zip archive d:compile.btm adding: compile.btm (188 bytes security) (stored 0%) C:\Haskell\docs>

I have investigated what some different platforms do: - Win32: PathAppend gives "C:\File"

what documentation on this function says? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Hi

...

I find it esthetically displeasing, but Bulat is correct; it is relied on in many situations by many programs.

It is not the "C:File" filename itself I have a problem with, but rather that "C:" "File" == "C:File".

That does seem very unintuative, but that's drives for you. For reference, I did follow the C# path functions as a general reference. The Shell ones are a kind of weird API that isn't in the built in Win32 API, and don't tend to be used that much.

Anyway, I am prepared to admit that I am wrong and that FilePath's behaviour is in fact correct. I guess drive names just really suck.

I think the drive behaviour is totally wrong on many levels. If you use something like Windows CE, then all paths have to be relative - this is a much better choice. Relative directories/drives are an artefact of combining an API with a user interface metaphore (the console) - and as a result are confusing.

A thing that is even more unexpected is:

...

"C:" "\\file" == "\\file"

A path like "\\file" is relative to the current drive. Giving a drive letter should make it completely absolute.

Perhaps - that does sound sensible. Is "\\file" relative or absolute? If its absolute, then combining with "C:" should not change anything. I think in reality its relative in a "drive" sense but absolute in a "path" sense. If anyone wants to knock up a design of a new API for these particularly difficult bits, feel free. Thanks Neil

The fact that the behavior (where a current directory is maintained) is related to the command interpreter certainly changes things. Command interpreter programs are not insignificant (if you use cygwin, or something similar), but logically if the win32 API behaves differently, then the win32 API behavior is (IMO) the properly expected behavior. What is the behavior of programs compiled within cygwin? Seth Kurtzberg Software Engineer Specializing in Security, Reliability, and the Hardware/Software Interface -----Original Message----- From: Bulat Ziganshin [mailto:bulat.ziganshin@gmail.com] Sent: Sunday, November 04, 2007 9:27 AM To: Twan van Laarhoven Cc: Seth Kurtzberg; 'Bulat Ziganshin'; libraries@haskell.org Subject: Re[2]: System.FilePath.joinDrive problem Hello Twan, Sunday, November 4, 2007, 2:33:44 AM, you wrote:

The reason I came upon this problem was that my %ProgramFiles% was set to "E:". For years this has worked without incident, all programs handle this just fine. The only program that doesn't accept this is cabal.

i think that you just violated agreement that here absolute path should be used. while your program was GUI ones, e: and e:\ was the same, but when you installed console program that inherits its environment from cmd, things goes wrong. is it possible to use "e:\" here? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Hello Twan, Saturday, November 3, 2007, 10:48:12 PM, you wrote:

- Win32: PathAppend gives "C:\File"

i've found and read its docs. my guess is that shell API was provided for GUI programs that doesn't have "current directory on other disks" concept, so your suggestion may be more appropriate for GUI apps, while current one conforms to the behavior of command-line utilities, including MS own ones at least for my own application i need current behavior and there is problem of backward compatibility with existing FilePath versions -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com