在文件命令（以及其他一些命令）中，是否已完成或计划执行任何关于无法关闭波形符替换的操作？我读到的最新内容是http://wiki.tcl.tk/28190，但是编程语言中的这种危险特性肯定不能被忽略吗？难道不是让C函数Tcl_TildeSubst（）检查是否存在全局Tcl变量，并且根据它进行扩展或不进行扩展吗？
我经常在shell脚本不足时编写Tcl脚本，并且很多时候它包括比较，复制，打开，删除和/或重命名文件。在运行脚本之前，我总是使用find来检查以波浪号（〜）开头的文件名。我很想知道其他Tcl程序员是如何做到这一点的。
答案 0 :(得分：6)
Tilde替换仅发生在Tcl即将字符串解释为文件名的位置，并且只有在字符串的第一个字符为~时才会发生（如果字符在其他任何地方，则为纯粹正常）。完成了两个替换：
~独立或后跟目录分隔符，则它指的是您的主目录（严格来说，是指HOME环境变量中指定的目录，默认为您的主目录）。~后跟其他任何内容，则直到字符串末尾或第一个目录分隔符（以先到者为准）的文件名的其余部分将被解释为用户名，{{1序列被该用户的主目录替换（使用系统实用程序查找，如Unix上~user中列出的那样）。这些功能在安全口译员中被禁用，即使用/etc/passwd或interp create -safe创建的口译员。
阻止排名safe::interpCreate成为问题的最简单方法是将~置于其前面，并始终使用./选项-directory（否则它是Tcl中唯一可以模糊地产生这种文件名的地方;其他任何地方都可能是它的意图）。使用完整的文件名通常会导致整体问题减少（我建议如果可能的话，永远不要更改工作目录;这只会造成巨大的混乱）。
我不认为安全解释器是一种解决方法，因为它们还有许多其他受限制的功能（例如，默认情况下，根本没有访问文件系统。）
至于应该可以禁用它的建议......这是一个有趣的，但它从未被Tcl的指导委员会认真提出。问题是有很多代码假设当前的行为;我认为添加一个hack（例如，一个魔术不支持的变量）来关闭它不是一个特殊的问题 - 在扩展完成时有一个解释器上下文，所以检查一个Tcl变量以确定是否这样做是微不足道的 - 但我个人非常担心这种变化会意外地破坏什么。
Stack Overflow不是讨论此类更改的非常好的环境。你最好不要问tcl-core mailing list。请注意，这是一个相当强大的辩论室有时（虽然几乎总是有礼貌）。另一种选择（如果你喜欢IRC）就是在freenode上讨论#tcl。