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

Jens Mueller jens.k.mueller at gmx.de
Tue Mar 1 05:10:58 PST 2011


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.
The almost identical C functions are part of POSIX.1-2001 according to
the man page. Though I have to admit I have no idea whether Windows has
similar calls.

Jens


More information about the Digitalmars-d mailing list