Proposal for std.path replacement

[Lars T. Kyllingstad]

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.

-Lars