filepath should not return trailing path separators
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,
Bryan O'Sullivan wrote:
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/", "")
FWIW I think you're right here. But I thought I'd mention the following trick I cooked up recently. It meant that I didn't run into the above problem, and might be relevant for what you're doing: pathParents = scanl1 () . splitDirectories -- > scanl1 () (splitDirectories "/a/b/c") -- ["/","/a","/a/b","/a/b/c"] Cheers, Simon
Hi
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/", "")
FWIW I think you're right here.
In various discussions I think people argued for both - in "foo/" there is no filename, since foo has been explicitly marked as a directory. I guess in this case foo is actually the leafname, or something. If you are doing your recursion pattern I think takeDirectory would be better, since it always progresses upwards. I didn't intend people to call the split* functions that much. I'm happy with whatever consensus people reach. Thanks Neil
participants (3)
-
Bryan O'Sullivan -
Neil Mitchell -
Simon Marlow