file normalize name
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. A normalized path is an absolute path which has all '../', './' removed. Also it is one which is in the "standard" format for the native platform. On MacOS, Unix, this means the segments leading up to the path must be free of symbolic links/aliases (but the very last path component may be a symbolic link), and on Windows it also means means we want the long form with that form's case-dependence (which gives us a unique, case-dependent path). The one exception concerning the last link in the path is necessary, because Tcl or the user may wish to operate on the actual symbolic link itself (for example 'file delete', 'file rename', 'file copy' are defined to operate on symbolic links, not on the things that they point to).
See also:
Compatibility Wrapper
CMCc: [file normalize] emulation code taken from critcl.tcl, put into file forward compatibility in the hope that more people will use normalize, and move faster to 8.4 and later, as per DGP's suggestion:
DGP To really encourage Tcl 8.4 adoption, you should recast this as an addition to file forward compatibility so that user scripts actually use [file normalize] and not [file_normalize].
KPV: Both the real file normalize and this compatibility wrapper don't handle volume relative paths correctly, to wit [file normalize c:a/b] results in c:a/b. This is supposedly fixed in 8.4.5.
JMN : I don't understand this point. What is c:a/b supposed to be and why should file normalize do something to it? You can't type something like c:temp into the address bar of windows explorer for example. I would understand a 'volume relative path' to be something like c:/a/b
I find it strange that file join c: a b produces c:a/b instead of c:/a/b - surely this is where the error lies?
SLB Windows has the concept of a current directory per drive, a concept it inherited from DOS. From a Command Prompt you can do:
c: cd \winnt d: type c:setup.log
and see setup.log from the current directory \winnt on drive c:. To my mind it's a pretty obscure feature and I don't think it can be used from Windows Explorer. I'm inclined to agree that the behaviour of 'file join' is odd, though as always, if you change that behaviour you risk breaking some scripts.