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

Don nospam at nospam.com
Tue Mar 1 08:40:31 PST 2011


Steven Schveighoffer wrote:
> On Tue, 01 Mar 2011 09:01:49 -0500, Nick Sabalausky <a at a.a> wrote:
> 
>> "Lars T. Kyllingstad" <public at kyllingen.NOSPAMnet> wrote in message
>> news:ikis59$14ci$3 at digitalmars.com...
>>> On Tue, 01 Mar 2011 14:10:58 +0100, Jens Mueller wrote:
>>>>
>>>> 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.
>>>
>>> I have used Linux's basename and dirname commands as the model for my
>>> versions.  basename takes a suffix argument because Linux formally
>>> doesn't have the notion of a file extension.  A dot is a part of the 
>>> name
>>> just like any other character.
>>>
>>
>> People don't always realize it, but Windows really is the same way. It's
>> really only the user-level applications like Explorer that ever care 
>> about
>> "extension", and even then the extension is always just "everything after
>> the last dot in the filename". Anything beyond that is merely 
>> tradition and
>> convention. The only real difference is that windows has no standard
>> mechanism for looking at the content of the file to help determine its 
>> type.

No, it tries hard to make it look that way, but it's evolved from a 
system where extensions were fundamental.
Even now, an 8.3 filename still exists for every file.

> 
> Didn't the FAT16 filesystem require something in the name portion of the 
> 8.3 filename?

And the dot was not stored anywhere. Only 11 characters were stored. 
This was still true in Windows 3.1, and I think it wasn't even 
completely gone in Win95/98.


More information about the Digitalmars-d mailing list