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

[Lars T. Kyllingstad]

On Tue, 01 Mar 2011 14:10:58 +0100, Jens Mueller wrote:

> Lars T. Kyllingstad wrote:
>> 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 don't know whether this is useful but why not look at what is already
> there. Linux has a command called basename. For removing the extension
> it is a bit useless. Because you need to provide the extension as a
> second argument in that case. But maybe it is like this for a good
> reason. There is also dirname.

I have used Linux's basename and dirname commands as the model for my 
versions.  basename takes a suffix argument because Linux formally 
doesn't have the notion of a file extension.  A dot is a part of the name 
just like any other character.

-Lars