Stelian, i still think that it's not the right way to deal with directories...
i repeatedly struggle due to this behavior: (iolib.pathnames:file-path-directory (iolib.pathnames:file-path "/tmp/")) => (:ROOT)
i understand how posix behaves, but i think it's unrelated when it comes to file-paths dropping the leading slashes. some posix C calls are not the same as a high-level library storing separate path components internally in an object and providing such high-level functions as merging...
imho, it should be either that: 1) we go the posix way, but then don't define high level functions like file-path-directory
2) do define a file-path-directory, but make it so that: (iolib.pathnames:file-path-directory (iolib.pathnames:file-path "/tmp/")) => (:ROOT "tmp")
although, i'm probably not aware of all the design issues, like e.g. canonicalization...
On Wed, 2010-10-06 at 02:11 +0200, Attila Lendvai wrote:
Stelian, i still think that it's not the right way to deal with directories...
i repeatedly struggle due to this behavior: (iolib.pathnames:file-path-directory (iolib.pathnames:file-path "/tmp/")) => (:ROOT)
What's the problem exactly ?
i understand how posix behaves, but i think it's unrelated when it comes to file-paths dropping the leading slashes. some posix C calls are not the same as a high-level library storing separate path components internally in an object and providing such high-level functions as merging...
imho, it should be either that:
- we go the posix way, but then don't define high level functions
like file-path-directory
f-p-d is just the equivalent of the shell command "dirname"
- do define a file-path-directory, but make it so that:
(iolib.pathnames:file-path-directory (iolib.pathnames:file-path "/tmp/")) => (:ROOT "tmp")
this is not what dirname does
i repeatedly struggle due to this behavior: (iolib.pathnames:file-path-directory (iolib.pathnames:file-path "/tmp/")) => (:ROOT)
What's the problem exactly ?
i list a few cases that doesn't match my expectations when it comes to a high level lib dealing with file path parsing and manipulating:
(file-path-file-name (file-path "/tmp/foo/")) => "foo"
(file-path-file-type (file-path "/tmp/foo.bar/")) =>"bar"
(file-path-namestring (file-path "/tmp/foo/")) => "/tmp/foo"
this last one especially when interfacing with cl:ensure-directories-exist
-- attila
On Sun, 2010-10-10 at 13:24 +0200, Attila Lendvai wrote:
i repeatedly struggle due to this behavior: (iolib.pathnames:file-path-directory (iolib.pathnames:file-path "/tmp/")) => (:ROOT)
What's the problem exactly ?
i list a few cases that doesn't match my expectations when it comes to a high level lib dealing with file path parsing and manipulating:
(file-path-file-name (file-path "/tmp/foo/")) => "foo"
(file-path-file-type (file-path "/tmp/foo.bar/")) =>"bar"
On *nix and Windows, there's no syntactic difference between paths representing files and directories(except for a possible final slash), so this means that the fact that a path represents a directory must be baked into the application logic: if you know that for your purposes "/tmp/foo" must be a directory, then calling file-path-file-name on it is just nonsensical
(file-path-namestring (file-path "/tmp/foo/")) => "/tmp/foo"
this last one especially when interfacing with cl:ensure-directories-exist
Ok, I'll fix this because it would be useful that (string= <path> (file-path-namestring (file-path <path>))) be always T
-
Attila Lendvai -
Stelian Ionescu