当符号链接后跟`..`时，[file normalize $ path]和realpath（$ path）之间的行为差​​异

Question

我发现Tcl [file normalize $path]之间的行为有所不同 以及C中调用使用的路径分辨率，例如open()和 realpath()。

它围绕使用符号链接紧跟..。

设置：给定此目录结构（注意sidedir_link是指向a的链接 不同的目录）：

/tmp/fileA.txt
/tmp/sidedir/fileA.txt
/tmp/subdir/fileA.txt
/tmp/subdir/sidedir_link -> /tmp/sidedir

当前目录为/tmp/subdir，我已创建命令 utils::realpath是对C函数realpath()的Tcl调用 <stdlib.h>。

这是成绩单。前两个调用显示了两者如何解决符号问题 链接。最后两个显示处理时的行为差异 紧跟在符号链接之后的..。

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

注意：区别在于/tmp/subdir/fileA.txt与/tmp/fileA.txt。

具体来说，[file normalize $path]似乎在词汇上解析了.. 通过删除路径的前一部分，而C实际调用 解析符号链接，然后应用..。如果是符号链接 是/some/location/far/far/away，解决的路径是。{ /some/location/far/far/fileA.txt。

我在Tcl文档，wiki或bug中找不到任何提及 跟踪系统。

那么，这是一个Tcl错误吗？一个C库的bug？预期的行为？

我正在使用Tcl 8.4.9和Redhat 6（是的，有点落后于时代......）

注意：我可以在Tcl 8.6.1中重现相同的行为

这一点很重要的原因是Tcl / Tk GUI指示文件存在（因为它使用file命令），但是当后端实际使用C库调用打开文件时{{ 1}}，运行失败（因为路径不同，并且不存在）。

Answer 1

这对我来说闻起来很像一个错误 - 鉴于我记得路径名解析和规范化代码的历史，我不会感到惊讶 - 所以我做了Bug Ticket #6c49da8a19。我没有维护Tcl的这一部分所以除了通过提交错误报告之外我甚至不知道如何开始解决它。如果您想提供更多信息，请通过我们的问题跟踪器进行。