"Lars T. Kyllingstad" <[email protected]> wrote in message news:[email protected]... > 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 agree. I've always seen the ".tar" in "xxxx.tar.gz" as merely a convention indicating what the content of the ".gz" file is. I've even been getting into a similar habit with other file types. For instance, if I have a file "file.foo" using binary format "foo", and then dump some of its data into readable text, I'll name the resulting file "file.foo.txt" instead of "file.txt". It ain't a "foo" file at all, it just helps me know exactly what the txt file is describing.
