On Sunday 06 March 2011 03:56:53 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.
If there's a standard way to deal with that, then that's probably best. > > 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? I kind of like how your extension doesn't include the "." in it, since you'd often want to remove it anyway, but given this particular ambiguity, I think that it's probably better to go with the old way of including the "." in the extension. - Jonathan M Davis