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

[spir]

On 03/01/2011 10:31 AM, Nick Sabalausky wrote:
> "Jonathan M Davis"<jmdavisProg at gmx.com>  wrote in message
> news:mailman.2076.1298971012.4748.digitalmars-d at puremagic.com...
>>
>> 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.
>>
>
> Due to the practical need for dealing with Unixy systems (for instance, an
> external web server) and cross-OS compatibility, etc, I deal with
> extension-less files (and filenames that start with a dot) quite frequently
> even on Windows, and even though I'm primarily a Windows user.
>
> That reminds me of something I've often wondered, though: Does unix consider
> a file named ".bashrc" to be a nameless file with an extension of "bashrc",
> or just an extentionless file named ".bashrc"? (I know unix doesn't
> typically have a concept of file extension, it's all just part of the name,
> but unix programs will often care about the extension portion of a
> filename.)

To be consistent with how things work on Unixes, file names starting with a '.' 
should be special-cased.
This '.' is a conventional code just meaning normal users should not cope with 
such files/dirs during normal use (and thus such files do not appear on normal 
dir content lists). It definitely has nothing to do with the notion of 
extension (which as you say is not a primary notion on Unixes). Treating it as 
an extension would totally be buggy.

I would thus approve
	assert( getName("/home/me/.foo" == "/home/me/.foo" );
	assert( getName("/home/me/.foo.cfg" == "/home/me/.foo" );
on Unixes, provided this behaviour is well documented.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com