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 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).
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.
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.
escargo 29 Jul 2005 - I don't know if the following is a bug or a feature, but it's definitely a bad combination on Windows XP SP2:
If you are accessing a file from a browser (say, Firefox), your little address widget contains a string like this:
file:///C:/Temp/GoogleSearch.wsdl
If you feed this to a function that determines the "urn scheme" of the URL, you get back two pieces:
file /C:/Temp/GoogleSearch.wsdl
So far, not bad. However, if you feed /C:/Temp/GoogleSearch.wsdl into file normalize, what you get back is
C:Temp/GoogleSearch.wsdl
which doesn't exist.
It turns out that "file normalize C:/Temp/GoogleSearch.wsdl" returns "C:/Temp/GoogleSearch.wsdl", but "file normalize /C:/Temp/GoogleSearch.wsdl" returns "C:Temp/GoogleSearch.wsdl".
This is in ActiveTcl 8.4.9.
Is this expected behavior, or is it a bug?
Response: 8.4.11 changes this behavior. See bug 1194458.
HaO: file normalize will resolve junctions of the Windows NTFS file system and return the path without the junctions, if there is a component after the junction. This is specially helpful, if the junction has less access rights than the direct way (which is the case for localized "program files" folders of Windows Vista). I took the habbit, to pass any files in system folders by file normalize before accessing them.
Create a folder 'C:\test2' and a junction 'C:\test2_junction' to it.
In a dos box with administrator rights:
C:\Windows\system32> cd c:\ C:\> mkdir test2 C:\> mklink /j test2_junction test2
Now test file normalize in a wish console:
% file normalize c:/test2_junction c:/test2_junction % file normalize c:/test2_junction/test.txt c:/test2/test.txt
2013-01-08: All TCL version before 8.5.13, 8.6.0 have bugs with folder junctions, when the access rights are restricted tcl-Bugs-3092089 , tcl-Bugs-3587096 . They are hopefully just resolved.