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

Lars T. Kyllingstad public at kyllingen.NOSPAMnet
Tue Mar 1 02:30:56 PST 2011


On Tue, 01 Mar 2011 03:58:04 -0500, Nick Sabalausky wrote:

> 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.

I've also found a few cases like that.  In general, I think std.path 
takes the KISS approach, probably because it's the most efficient and 
works in most cases, but I'd rather it did the Right Thing (TM) that 
works in all cases.

Searching for the "extension dot" is one such case.  The simplest thing 
is of course to search for a '.' character.  std.path does that, and also 
stops (I hope) at a dir separator.  However, it doesn't take into account 
the fact that Windows has two types of dir separator, nor that a dir 
separator immediately followed by a dot denotes a hidden file on POSIX.

Another problem with std.path is the horribly inconsistent naming 
scheme.  I mean, rel2abs?  Come on!

A while ago I started working on a rewrite of std.path, but it's only 
halfway done because I got derailed by other things.  Perhaps it's time 
to pick up on it again?

  http://kyllingen.net/code/ltk/doc/path.html
  https://github.com/kyllingstad/ltk/blob/master/ltk/path.d

-Lars


More information about the Digitalmars-d mailing list