Hi, Neil -
I'm writing some filesystem traversal code using filepath at the moment,
and I am a bit disappointed to find it more error-prone and cumbersome
than I had hoped.
The root of my problem is that splitFileName leaves a trailing path
separator on the end of the first element of the tuple it returns:
splitFileName "foo/bar" ==> ("foo/", "bar")
If I'm recursing up a file hierarchy towards the root directory (a
common thing to do), this trailing path separator is a pain. Either I
forget that it's there and infinitely loop in the same directory over
and over again, due to this behaviour:
splitFileName "foo/" ==> ("foo/", "")
Or I have to remove it, with an unaesthetically named function:
splitFileName (dropTrailingPathSeparator "foo/") ==> ("", "foo")
Having the trailing path separator omitted in the result of
splitFileName and friends would both get rid of the possibility of the
recursion bug (I'm surely not the only one who'll be bitten by it) and
greatly reduce the frequency of the need to import and call
dropTrailingPathSeparator.
I don't know how open the library is to such a change, now that GHC
6.6.1 ships with filepath, but I consider the current behaviour to be
quite unfortunate and undesirable, and very much worth fixing.
FWIW, Python's os.path.split has the trailing-"/"-elision behaviour I am
advocating.
Thanks for your work on filepath. I am glad to have it; I'd just be
gladder if it wasn't so tricksy.
Regards,