filepath

[Simon Marlow]

Ian Lynagh wrote:
> On Sun, Dec 09, 2007 at 09:17:56PM +0000, Neil Mitchell wrote:
>>> The first is this:
>>>     Prelude System.FilePath> "." </> "foo"
>>>     "./foo"
>>> which means we get things like
>>>     [2 of 2] Compiling GHC.Foo          ( ./GHC/Foo.hs, ./GHC/Foo.o )
>>> rather than
>>>     [2 of 2] Compiling GHC.Foo          ( GHC/Foo.hs, GHC/Foo.o )
>>> Is there a reason the result shouldn't be "foo"?
>> My best guess is that "." </> "foo" should equal "./foo". However, I'm
>> not overly wedded to this behaviour, so if the general consensus is
>> the other way, I'll happily implement that.
>>
>>> Possibly relatedly, the current directory seems to be "" rather than
>>> ".". This turns up in at least a couple of areas:
>>>     Prelude System.FilePath> normalise "."
>>>     ""
>> I would say this is a bug, and that normalise "." should be ".".
> 
> The two answers above together mean that the property
> 
>     \x y -> let x' = normalise x
>                 y' = normalise y
>                 z = x' </> y'
>             in z == normalise z'
> 
> doesn't hold (for x = ".", y = "foo"), but it is one I would expect to
> hold.

I think you have an extra ' on the last line of the code above.  But 
anyway, why do you expect that to hold?

There's an implicit context in the definition of normalise.  The invariant 
we want is that I can use "normalise x" wherever I use "x" and get the same 
result.  But it can't be that simple, because we can always tell the 
difference by looking at the string, so we have to define the allowable 
context carefully.  It looks like the context we're aiming for is "all 
functions in System.FilePath, System.IO and System.Directory".

Which would make "./foo" the same as "foo": as far as the OS is concerned, 
these always mean the same thing.

execvp mucks things up by giving a special meaning to "foo".  But all this 
means is that execvp (and hence rawSystem) is a context that can tell the 
difference between "normalise x" and "x", and therefore you shouldn't call 
normalise on the path given to rawSystem.

>>>     Prelude System.FilePath> splitFileName "foo"
>>>     ("","foo")
>> I'd say this was expected. In a similar way, takeDirectory "foo" gives
>> "", not "./".
> 
> I'd expect takeDirectory "foo" to be "." and dropFileName "foo" to be
> "./" too.

Right, me too.

But this is more of a pervasive design choice.  It looks like 
System.FilePath consistently treats "" as a valid FilePath meaning "the 
current directory", and this would mean changing that policy.

As far as System.Directory is concerned, "" is not a valid FilePath (i.e. 
you can't say getDirectoryContents ""), and the current directory is 
denoted by ".".  So it would seem sensible for System.FilePath to behave in 
the same way.

But then (splitFileName "foo") would have to give (".", "foo"), and therefore

   uncurry (</>) (splitFileName x)  /=  x

which seems odd.  But perhaps the right property is

   normalise (uncurry (</>) (splitFileName x))  ==  normalise x

Cheers,
	Simon