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

[retard]

Tue, 01 Mar 2011 11:04:53 -0800, Jonathan M Davis wrote:

> On Tuesday, March 01, 2011 06:54:27 Andrei Alexandrescu wrote:
>> 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?"
> 
> Yeah, you're probably right. I definitely think of file.tar.gz as having
> the extension tar.gz, not gz, but it makes far more sense from a
> processing point of view to treat gz as the extension. You can then get
> the extension of the remainder if you want, whereas if you treated
> tar.gz as the extension, that wouldn't work all that well (particularly
> since std.path treats the dot as part of the extension instead of as a
> separator).

In the *nix land most common extensions of this sort 
are .tar.gz, .tar.bz2, .tgz, .ps.gz, .pds.gz, and .svgz. The files are 
gzip or bzip2 packed single files, nothing more. Some tools only manage 
to open them if the extension is correct and otherwise treat them as 
black box archives. For example GNOME's pdf viewer refuses to open 
document.gz, but renaming it to document.ps.gz makes it viewable, 
assuming the file is a gzipped postscript document.