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

Jonathan M Davis jmdavisProg at gmx.com
Tue Mar 1 02:54:04 PST 2011


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


More information about the Digitalmars-d mailing list