Revision as of 21:20, 17 July 2006
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 + Heirarchical 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
makeValid, should deal with prn/con/nul etc. > That is true. But, there are many cases where software used primarily in > Unix fails when ported to Windows due to problems with "con," "prn," et al. Having reconsidered it, you're right - its not a valid path. I'll add a fix for this.
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.
> I guess you mean "makeValid" replaces them with underscores. That wasn't > clear in the documentation but I understand what you are trying to do now. I'll make the docs clearer - I have done a lot of work on them this weekend, but its not quite clear how makeValid works even still - certainly worth a fix.
I think that the xxxDrive functions should only be exported from System.FilePath.Windows and no System.FilePath since it is unclear as to how they should be used effectively by cross-platform software. -- thinking....
Another thing I thought of would be a "canonicalPath" IO action (canonicalPath :: FilePath -> IO FilePath) that returns a FilePath that implements case-preserving-case-insensitive matching. For example, if there is a file named "Hello There.txt" in C:\, then (canonicalPath "c:\hello there.txt ") would give "C:\Hello There.txt").
2 Thoughts on FilePath as a abstract type
Add them here :)