FilePath

I have written a System.FilePath module in part based on the one in Yhc, and in part based on the one in Cabal (thanks to Lemmih). The aim is to try and get this module into the base package, as FilePath's are something many programs use, but its all too easy to hack up a little function that gets it right most of the time on most platforms, and there lies a source of bugs.

This module is Posix (Linux) and Windows capable - just import System.FilePath and it will pick the right one. Of course, if you demand Windows paths on all OS's, then System.FilePath.Windows will give you that (same with Posix). Written in Haskell 98 + Hierarchical Modules.

• Homepage: http://www-users.cs.york.ac.uk/~ndm/projects/libraries.php
• Haddock: http://www-users.cs.york.ac.uk/~ndm/projects/filepath/System-FilePath.html
• Darcs: darcs get http://www.cs.york.ac.uk/fp/darcs/filepath
• Source: http://www.cs.york.ac.uk/fp/darcs/filepath/System/FilePath.hs
• Readme: http://www.cs.york.ac.uk/fp/darcs/filepath/readme.txt

If you go to the haddock page there are a few little examples at the top of the file.

The Yhc project, hquickfile and a few other utilites are already using this module succesfully.

Comments welcome. Thanks

Thoughts/Todo

For that there would need to be some FilePath function such as checkDownstream :: FilePath -> FilePath -> Bool which checks if some path is below another in the tree. I'll think about adding that one. This function needs to be seriously robust!

I haven't been following this discussion very closely, but this caught my eye. Has anyone pointed out yet that eliminating ".." in a FilePath isn't valid in the presence of symbolic links? I vaguely recall that this is why Krasimir's System.FilePath library doesn't include normalisation. Normalisation that just changes separators, removes redundant separators and removes "." components is probably ok.

Ok, I'll remove this behaviour

I don't really see the point of fullPathWith. Isn't it just combine?

It also applies normalise to the result, although I'm not sure thats a particularly useful thing to do. I'll think about this.

I think shortPath is on dodgy ground, given the difficulty with normalising FilePaths, and the fact that paths are not unique in the presence of symlinks.

I think this is still a useful thing, but I'll think harder about it in relation to symlinks, and figure out what properties it should have.

The temporary file stuff is wrong - see System.IO.openTemporaryFile. The only way to reliably create a temporary file is to open it at the same time, otherwise there's a race condition.

Looking at it again, I'm not sure that the temporary operations belong in this module. Ditto for the directory operations. It would be handy if the directory operations (particularly ensureDirectory) were somewhere else in the standard libraries though.

Thoughts on FilePath as a abstract type

Add them here :)