On Sun, 06 Mar 2011 15:54:19 +0100, spir wrote: > On 03/06/2011 12:56 PM, Lars T. Kyllingstad wrote: >> On Sun, 06 Mar 2011 09:37:15 +0100, Rainer Schuetze wrote: >> >>> Looks good overall. I have a few comments and nitpicks though: >>> >>> > basename("dir/subdir/") --> "subdir" >>> > directory("dir/subdir/") --> "dir" >>> >>> Is this what everybody expects? I'm not sure, but another possibility >>> would be to treat these as if "dir/subdir/." is passed. >> >> I don't know about everybody, but it is what *NIX users expect, at >> least. I have written those functions so they adhere to the POSIX >> requirements for the 'basename' and 'dirname' commands. >> >> >>> What is the >>> result of directory("/") or directory("d:/")? >> >> "/" and "d:/", respectively. The first is what 'dirname' prints, and >> the second is the natural extension to Windows paths. (I believe I >> have covered most corner cases in the unittests. I think it would just >> be confusing to add all of them to the documentation.) >> >> >>> > extension("file") --> "" extension("file.ext") >>> > --> "ext" >>> >>> What about "file."? I tried it on NTFS, but trailing '.' seems to >>> always be cut off. Is it possible to create such a file on unix >>> systems? If yes, you won't be able to recreate it from the result of >>> basename() and extension(). >> >> Good point. I don't know if there is any kind of precedent here. What >> do others think? >> >> >>> What about network shares like "\\server\share\dir\file"? Maybe it >>> should also be shown in the examples? Does the "\\server" part need >>> special consideration? >> >> Hmm.. that's another good point. I haven't even though of those, but >> they should probably be covered as well. I'll look into it. > > What about extending the notion of 'device' (see other post) to cover > 'http://' and "ftp://"? > Would it be complicated?
I don't think std.path should handle general URIs. It should only have to deal with the kind of paths you can pass to the functions in std.file and std.stdio. -Lars