Hi
It's already there - see System.Directory.createDirectoryIfMIssing. I'd missed that one entirely, and I think other people had (because I added ensureDirectory at a request of several people), will go.
If we have shortPath at all, perhaps it would be better named relativeToCurrentDIrectory? Make sense, shortPath is not particularly well defined by name.
I'm not sure about canonicalPath. This interface seems to suffer from the same race conditions as the temporary file interface: the answer is immediately invalid, so you can't rely on it. The main purpose of canoncialPath is to fix the case on Windows, so "c:\my documents\file.doc" becomes "C:\My Documents\file.doc" if that is the case correct version of the file. I think this function will not actually change the file with relation to the underying file system, so should be race free. (I will document more to make the operation clearer)
We should avoid referring to $PATH as the "path", since we already have FilePath.
Agreed, but I couldn't come up with a better name, if anyone has any suggestions.
"search path" seems the best option, I think. Still has the Path in the name, which is the confusing bit, to me at least.
Has a FilePath of "/usr/bin/ghc" and a FileName of "ghc".
Then this seems inconsistent with the naming of splitFileName, which should be splitFilePath.
Isn't joinFilename the same as combine? Yes, I hadn't spotted thats (the code is duplicated, and written in a different style). However I feel its useful to have both of them in
No, since its splits a FilePath into a FileName and the rest left over. In the same way that splitExtension takes a FilePath, but splits into an extension. I have named the operations by the result, rather than the input (which is almost always a FilePath) there, since having the join/split duality is quite handy, and combine "conceptually" operates on a lot more than just filenames.
get/setFilename are ok, but I prefer to reserve get/set for statelike things. Perhaps instead:
directoryOf :: FilePath -> String filenameOf :: FilePath -> String extensionOf :: FilePath -> String basenaneOf :: FilePath -> String
replaceFilename = joinFilePath . directoryOf replaceDirectory = flip joinFilePath . filenameOf
I don't like directoryOf/replaceDirectory as names, since one has Directory at the front and the other at the end. However I'm flexible about this. Ideally I wanted to use the record constructors: mypath{directory = "value"} directory mypath. Unfortunately that can't be done with FilePath = String, and even with a separate constructor and records its not particularly nice to write.
(unfortunately this use of basename is inconsistent with the Unix command, perhaps there's a better name?). If anyone can think of one... Naming is not my strong point!
Thanks Neil