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

[Andrei Alexandrescu]

On 3/1/11 4:54 AM, Jonathan M Davis wrote:
> On Tuesday 01 March 2011 02:49:31 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?
>
> I'd definitely argue that everything to the right of the first dot in the file name
> is the extension, but I don't know how that's generally handled by programs or
> OSes that actually care about extensions.
>
> - Jonathan M Davis

If we want to stick with the notion of the extension, it should be the 
thing after the last dot (if the dot isn't the first character of the 
name). Thus .bashrc has no extension and foo.tar.gz has extension gz. 
That facilitates asking questions such as "was this file gz-compressed?"

Andrei