Version 8 of file nativename

Updated 2005-04-16 13:18:43 by MG

file nativename name

Returns the platform-specific name of the file name. This is useful if the filename is needed to pass to a platform-specific call, such as exec under Windows or AppleScript on the Macintosh.

LES: What is the difference between file nativename and file normalize? What does file nativename do that file normalize doesn't?

RLH: file normalize "Returns a unique normalised path representation for the file-system object (file, directory, link, etc), whose string value can be used as a unique identifier for it. "

MG Basically, file normalize expands ., .. and ~ to the "proper" elements, and file nativename shows the platform-specific directory separators. Usually, for the purposes of displaying a path, you want to use both. For example:

 (Griffiths) 2 % pwd
 C:/Documents and Settings/Griffiths
 (Griffiths) 3 % set path [file join .. .. windows]
 ../../windows
 (Griffiths) 4 % file normalize $path
 C:/WINDOWS
 (Griffiths) 5 % file nativename $path
 ..\..\windows
 (Griffiths) 6 % file nativename [file normalize $path]
 C:\WINDOWS
 (Griffiths) 7 % file normalize [file nativename $path]
 C:/WINDOWS

So, to display a path the platform-specific way,

 file nativename [file normalize $path]

is the thing to use, as it expands everything properly. On Windows, you can go a step further, and use

 file nativename [file attributes [file normalize $path] -shortname]
 file nativename [file attributes [file normalize $path] -longname]

to guarantee you get the short (MS-DOS type 8.3) names, or the longer, full/"real" file names. (You still need the file nativename on the outside, though, to get backslashes, rather than forward slashes.)

Vince says that [file normalize] is guaranteed to be the 'longname', so the second example is longer than necessary. file nativename [file normalize $path] will do the same thing.

LES tells RLH: I am lazy indeed, but not THAT lazy. I asked that question because I read the manual, but that wording did not help me at all. That is a common problem in Tcl's documentation. To the other Tclers, I say that the explanations offered should be clear enough, but I am still puzzled because as a novice programmer I've certainly had problems with paths, but always fixed them completely with no more than file normalize. I still don't see why anyone would need [file nativename].

MG The main use (as far as I'm concerned from how I've used it) is to make programs look more native to the platform they're on. When you're on MS Windows (and only use it/rarely use anything else), paths with forward slashes just don't look right. Since they'll all work just the same internally, it's better IMHO to give users the right look for their platform - it's less confusing, and looks more professional, I think.


See also:


Tcl syntax help - Category Command - Category Introspection