title: Difference in behavior between [file normalize $path] and realpath($path) when symbolic link is followed by `..`
body: <p>I have found a difference in behavior between Tcl's <code>[file normalize $path]</code>
  and the path resolution used by the calls in C, such as <code>open()</code> and
  <code>realpath()</code>.</p>
  
  <p>It revolves around the use of symbolic links immediately followed by <code>..</code>.</p>
  
  <p>The setup: given this directory structure (notice that <code>sidedir_link</code> is a link to a
  different directory):</p>
  
  <pre><code>/tmp/fileA.txt
  /tmp/sidedir/fileA.txt
  /tmp/subdir/fileA.txt
  /tmp/subdir/sidedir_link -&gt; /tmp/sidedir
  </code></pre>
  
  <p>the current directory is <code>/tmp/subdir</code>, and I have created the command
  <code>utils::realpath</code> to be a Tcl call to the C function <code>realpath()</code> in
  <code>&lt;stdlib.h&gt;</code>.</p>
  
  <p>Here's the transcript.  The first two calls show how both resolve a symbolic
  link.  And the last two show the difference in behavior when dealing with
  the <code>..</code> that immediately follows the symbolic link.</p>
  
  <pre><code>wish% file normalize sidedir_link/fileA.txt
  /tmp/sidedir/fileA.txt
  wish% ::utils::realpath sidedir_link/fileA.txt
  /tmp/sidedir/fileA.txt
  wish% file normalize sidedir_link/../fileA.txt
  /tmp/subdir/fileA.txt
  wish% ::utils::realpath sidedir_link/../fileA.txt
  /tmp/fileA.txt
  </code></pre>
  
  <p><em>Note:</em> The difference is <code>/tmp/subdir/fileA.txt</code> versus <code>/tmp/fileA.txt</code>.</p>
  
  <p>Specifically, <code>[file normalize $path]</code> appears to lexically resolve the <code>..</code>
  by removing the preceding portion of the path, whereas the C calls actually
  resolve the symbolic link and <strong>then</strong> apply the <code>..</code>.  If the symbolic link
  were to <code>/some/location/far/far/away</code>, the resolved path would be
  <code>/some/location/far/far/fileA.txt</code>.</p>
  
  <p>I couldn't find any mention of this in the Tcl docs, the wiki, or in the bug
  tracking system.</p>
  
  <p>So, is this a Tcl bug?  A C-library bug?  Expected behavior?</p>
  
  <p>I'm using Tcl 8.4.9 and Redhat 6 (yes, a bit behind the times...)</p>
  
  <p><em>Note:</em> I can reproduce the same behavior in Tcl 8.6.1</p>
  
  <p>The reason this is important is that the Tcl/Tk GUI is indicating that a file exists (because it uses the <code>file</code> commands), but when the backend actually opens the file using the C-library call <code>open()</code>, the run fails (because the path is different, and doesn't exist).</p>