'''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 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:

   * [file]
   * [file nativename]
   * [file readlink]

----
'''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.

----
[Tcl syntax help] -
[Category Command] -
[Category Introspection]