System.FilePath.joinDrive problem

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

System.FilePath.joinDrive problem

Twan van Laarhoven
Hello all,

The joinDrive function currently produces paths such as "C:File" when
calling  "C:" </> "File". This is apparently handled in a special case:

 >              | otherwise = case a of
 >                                [a1,':'] | isLetter a1 -> a ++ b
 >                                _ -> a ++ [pathSeparator] ++ b

This seems wrong, as far as I know "C:File" is not a valid path. What is
the reason for this special case?

In particular this problem results in cabal wanting to install packages
to "E:Haskell" on my computer (unless I pass a --prefix flag).

Twan
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: System.FilePath.joinDrive problem

Bulat Ziganshin-2
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)

--
Best regards,
 Bulat                            mailto:[hidden email]

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: System.FilePath.joinDrive problem

Aaron Denney
In reply to this post by Twan van Laarhoven
On 2007-11-03, Twan van Laarhoven <[hidden email]> wrote:

> Hello all,
>
> The joinDrive function currently produces paths such as "C:File" when
> calling  "C:" </> "File". This is apparently handled in a special case:
>
> >              | otherwise = case a of
> >                                [a1,':'] | isLetter a1 -> a ++ b
> >                                _ -> a ++ [pathSeparator] ++ b
>
> This seems wrong, as far as I know "C:File" is not a valid path. What is
> the reason for this special case?

C:File refers to the file "File" in the current directory on drive c:.
Each drive in windows has its own current directory.

--
Aaron Denney
-><-

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: System.FilePath.joinDrive problem

Twan van Laarhoven
In reply to this post by Bulat Ziganshin-2
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
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re[2]: System.FilePath.joinDrive problem

Bulat Ziganshin-2
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:[hidden email]

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re[2]: System.FilePath.joinDrive problem

Bulat Ziganshin-2
In reply to this post by Twan van Laarhoven
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:[hidden email]

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

RE: Re[2]: System.FilePath.joinDrive problem

sethk
In reply to this post by Bulat Ziganshin-2
I find it esthetically displeasing, but Bulat is correct; it is relied on in
many situations by many programs.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
On Behalf Of Bulat Ziganshin
Sent: Saturday, November 03, 2007 4:22 PM
To: Twan van Laarhoven
Cc: [hidden email]; 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:[hidden email]

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: System.FilePath.joinDrive problem

Twan van Laarhoven
Seth Kurtzberg wrote:

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

When you are combining "C:" with a filename you are treating it as a
kind of directory name. Almost all windows programs *will* treat "C:"
the same as "C:\", and from the user's point of view this is IMO correct.

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.


On the other hand, many other functions do treat "C:" as a kind of
relative path name, from that view the current behaviour makes sense.

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.


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.

Twan
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: System.FilePath.joinDrive problem

Neil Mitchell
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
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re[2]: System.FilePath.joinDrive problem

Bulat Ziganshin-2
In reply to this post by Twan van Laarhoven
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:[hidden email]

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

RE: Re[2]: System.FilePath.joinDrive problem

sethk
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:[hidden email]]
Sent: Sunday, November 04, 2007 9:27 AM
To: Twan van Laarhoven
Cc: Seth Kurtzberg; 'Bulat Ziganshin'; [hidden email]
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:[hidden email]



_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re[4]: System.FilePath.joinDrive problem

Bulat Ziganshin-2
Hello Seth,

Sunday, November 4, 2007, 10:15:14 PM, you wrote:

i just simplified my description. console programs has current
directory" on each drive and inherit it from parent program. i don't
know exact behavior of GUI programs. shlwapi.dll is just helper dll
which contains various string functions in particular. i don't think
that it defines "Windows API" although i may be wrong here

i don't use cygwin and imho its behavior is not definitive in this case


> 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:[hidden email]]
> Sent: Sunday, November 04, 2007 9:27 AM
> To: Twan van Laarhoven
> Cc: Seth Kurtzberg; 'Bulat Ziganshin'; [hidden email]
> 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:[hidden email]

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries