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

[Jonathan M Davis]

On Tuesday 01 March 2011 00:58:04 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 agree. I would _think_ that it would return the file name minus the 
extension and that if there is no extension, then it would just return the file 
name.

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


That's a bug IMHO. Presumably, the implementation didn't take the possibility of 
directory names with dots in them into account. Now, it _does_ follow what it 
says in the docs quite exactly, but that definitely seems off to me.
 
> 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 think that I agree with you on all counts. I can understand if the path stuff 
can't deal with / or \ in file names (that's probably not worth trying to get to 
work right), but it _should_ be able to handle directories with dots in them and 
files with no extension. Files without extension may be uncommon in Windows, but 
they're common enough on Linux.

- Jonathan M Davis