[Haskell-cafe] Re: Suggested additions to System.FilePath.Posix/Windows

[Marcus D. Gabriel]

Simon Marlow wrote:
> Brandon S. Allbery KF8NH wrote:
>> On Sep 19, 2009, at 07:45 , Duncan Coutts wrote:
>>> On Thu, 2009-09-17 at 11:58 +0200, Marcus D. Gabriel wrote:
>>>>> -- | 'reduceFilePath' returns a pathname that is reduced to canonical
>>>>> -- form equivalent to that of ksh(1), that is, symbolic link names
>>>>> are
>>>>> -- treated literally when finding the directory name.  See @cd -L@ of
>>>>> -- ksh(1).  Specifically, extraneous separators @(\"/\")@, dot
>>>>> -- @(\".\")@, and double-dot @(\"..\")@ directories are removed.
>>>
>>> So it's like the existing System.Directory.canonicalizePath but it's
>>> pure and it does not do anything with symlinks. On the other hand
>>> because it's pure it can do something with non-local paths.
>>>
>>> Is there anything POSIX-specific about this? I don't see it.
>>
>> It's making assumptions about the safety of eliding "..".  (What does
>> \\machine\share\..\ do?)  On the other hand that's also unsafe on
>> POSIX in the presence of symlinks.  In general I consider path
>> cleanup not involving validation against the filesystem to be risky.
>
> I agree; this came up before during the design of System.FilePath, and
> it's why the current library doesn't have a way to remove "..".  The
> docs should probably explain this point, because it's non-obvious that
> you can't just "clean up" a path to remove the ".." and end up with
> something that means the same thing.
>
> Cheers,
>     Simon

A few points to explain my point of view.  It's a little long.

Yes, reduceFilePath is pure and not an IO action, but this was not
important for my application.  What counted is the preservation of the
logical structure of the path which was a design choice and that the
paths in question may no longer exist in the file system.  Thus
canonicalizePath could not help me.  These are the most important
points.  For me, if these two points are not of generally interest, than
there should be no System.FilePath.reduceFilePath or equivalent.

The essential POSIX standard (IEEE Std 1003.1) can be found at

<http://www.opengroup.org/onlinepubs/009695399/utilities/cd.html>,

that is, cd - change the working directory.  The key points are in the
OPTIONS section and steps 8 and 9 of the DESCRIPTIONS section.  I used
ksh(1) as my guide, but bash(1) or dash(1) work also.  See also

<http://www.opengroup.org/onlinepubs/009695399/>,

that is, section 4.11 Pathname Resolution.

So, the function reduceFilePath does not make any assumptions about
eliding of "..", it simple attempts to implement the behaviour of cd -L
of a POSIX shell consistent with Path Resolution of section 4.11 minus
the dereferencing of symbolic links.  Whether reduceFilePath does this
correctly or not is another question.  (It does not, sorry about that,
but I have an older version that does minus the leading double slash rule.)

Although it is true that if you just clean up the path it may no longer
resolve to the same object in the file system as would the result of a
call to canonicalizePath, Python has a library function whose name I
cannot remember in which the documentation just states that this may
change the meaning of the path, that is, let the programmer beware.

In my case, I verified and resolved the initial inputs from the user so
that either an error message occurred or I could use reduceFilePath in
confidence during processing.  That is to say, the file system
validation was done upfront so that I could safely maintain the logical
structure which was the design choice and in certain cases continue
processing even if the pathnames no longer referred to anything.

This means that \\machine\share\..\ is \\machine\ logically.  Thus, the
application should either not use reduceFilePath or it should set up
conditions to avoid or catch this case.  The blind or unthinking use of
reduceFilePath is not only risky, it's a mistake.  Just like
unsafePerformIO, let the programmer beware.

If reduceFilePath is useless under Windows but at least makes some kind
of sense, then for me, a debugged, POSIX compliant
System.FilePath.reduceFilePath would have been nice.   So I propose it. 
If it makes absolutely no sense under Windows, then drop it so as to
maintain the interface which I used wherever I could and appreciated
greatly.

Cheers,
- Marcus