std.path.getName(): Screwy by design?

[Nick Sabalausky]

"Lars T. Kyllingstad" <public at kyllingen.NOSPAMnet> wrote in message 
news:ikilpg$2vba$4 at digitalmars.com...
> On Tue, 01 Mar 2011 11:49:31 +0100, Daniel Gibson wrote:
>
>> Am 01.03.2011 09:58, schrieb Nick Sabalausky:
>>> According to the docs, std.path.getName() "Returns the extensionless
>>> version of a filename or path."
>>>
>>> But the doc also says that if the filename doesn't have a dot, then it
>>> returns null (and I've verified that on DMD 2.050). Isn't that a bit
>>> ridiculous? Shouldn't it still return the extensionless version even if
>>> it doesn't have an extension? Ie, return the original string.
>>>
>>> I would expect all of the following to pass, but currently (by design)
>>> only the first two pass:
>>>
>>> assert(getName(r"file.ext") == r"file");
>>> assert(getName(r"/path/file.ext") == r"/path/file");
>>>
>>> assert(getName(r"file") == r"file");
>>> assert(getName(r"/path/file") == r"/path/file");
>>>
>>> The current behavior seems useless.
>>>
>>> Additionally, this also seems screwy:
>>>
>>> // Currently passes:
>>> assert(getName(r"/pa.th/file") == r"/pa");
>>>
>>> WTF? The docs seem to suggest that's by design, but I can't imagine
>>> why. Even on Windows it's not as if filenames can contain forward
>>> slashes (and except for the command-line, accessing paths with
>>> forward-slash separators works fine on Windows).
>>>
>>> Fortunately, the docs do seem to be wrong about this:
>>>
>>> version(Windows)
>>>       getName(r"d:\path.two\bar") =>  null
>>>
>>> That currently returns r"d:\path.two\bar" as I would expect.
>>>
>>> If those in charge agree with me on all of the this, I'd be glad to go
>>> through std.path, fix all of that, check for any other issues and
>>> submit a modified std.path with updated examples and unittests for
>>> approval.
>>>
>>>
>> And what about "foo.tar.gz"? Does it return "foo" or "foo.tar"? And what
>> should be returned?
>
> That's a good question.  And what about "foo-1.0.4.tar.gz"?  I say only
> the last extension should be returned.  foo.tar.gz is a gzip file, not a
> tar file.  The fact that you can pass one directly to tar is simply a
> convenience.
>

I agree. I've always seen the ".tar" in "xxxx.tar.gz" as merely a convention 
indicating what the content of the ".gz" file is. I've even been getting 
into a similar habit with other file types. For instance, if I have a file 
"file.foo" using binary format "foo", and then dump some of its data into 
readable text, I'll name the resulting file "file.foo.txt" instead of 
"file.txt". It ain't a "foo" file at all, it just helps me know exactly what 
the txt file is describing.