我正在处理将文件位置传递给 scp 子进程的 python 脚本。这一切都很好，但我处于这样一种情况，我可能最终将一个路径与一个文件名连接起来，这样路径中就有一个双 ' /。我知道 bash 不关心您是否有多个文件分隔符，但我想知道如何纠正它。是 bash 去掉了额外的/s 还是真的无关紧要？
我问是因为它会为我节省几行代码来/在连接时检查额外的s。我知道这没什么大不了的，但我也很好奇。我有一个包含行cd //usr（而不是cd /usr）的 bash 脚本，这似乎暗示/在路径中使用多个s可能很重要
在整个 POSIX 规范中，都有规定 ( 1 , 2 , 3 ...) 允许实现/特别处理以 2 开头的路径。
POSIX 应用程序（根据 POSIX 规范编写的应用程序可移植到所有 POSIX 兼容系统）不能假设//foo/bar与 相同/foo/bar（尽管他们可以假设///foo/bar与 相同/foo/bar）。
现在那些//foo特殊对待的 POSIX 系统（历史悠久且仍在维护）是什么？我相信（我现在被证明是错误的）微软为他们的 Unix 变体 (XENIX) 和可能的 Windows POSIX 层推送了 POSIX 条款（有人能证实吗？）。
它被 Cygwin 使用，Cygwin 也是 Microsoft Windows 的类似 POSIX 的层。是否有任何非 Microsoft Windows 系统？开放虚拟机？
在//foo/bar特殊的系统上，它用于什么？//host/path用于网络文件系统访问？虚拟文件系统？
某些运行在类 Unix 系统上的应用程序（如果不是系统的 API）是否会//foo/bar特别处理路径（在它们否则将其/foo/bar视为文件系统上的路径的上下文中）？
编辑，此后我在奥斯汀组邮件列表上询问了//foo/bar有关规范中处理起源的问题，并且讨论很有趣（至少从考古学的角度来看）。
如果没有给出路径，为什么会find打印出导致./结果的结果？
$ find
./file1
./file2
./file3
不打印出来的原因是什么？
$ find
file1
file2
file3
这是一个错误，当find ./path/here/我得到：
./path/here//foo
./path/here//bar
我知道find希望我指定不带斜杠的路径，但它肯定可以检测到制表符完成留给我的路径并相应地调整其输出。有什么理由不这样做吗？