我正在处理将文件位置传递给 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有关规范中处理起源的问题，并且讨论很有趣（至少从考古学的角度来看）。
我在 linux 中使用的大多数命令的行为都完全相同，无论我是否/在目录名称的末尾包含斜杠字符。
例如：
ls /home/cklein
ls /home/cklein/
cp foo bar
cp foo/ bar/
这个尾部斜杠什么时候重要？尾部斜杠的语义是什么？
我对以下脚本 ( hello.go)感到困惑。
//usr/bin/env go run $0 $@ ; exit
package main
import "fmt"
func main() {
fmt.Printf("hello, world\n")
}
它可以执行。（在 MacOS X 10.9.5 上）
$ chmod +x hello.go
$ ./hello.go
hello, world
我还没有听说过以 开头的shebang //。当我在脚本顶部插入一个空行时，它仍然有效。为什么这个脚本有效？
不要cd dir/subdir/和cd dir/subdir//意味着在UNIX一样吗？
后期会解决吗？不然有什么特别的意义吗？
cd、mv、ls 或任何命令。
在 unix/linux 中，路径中任意数量的连续正斜杠通常等效于单个正斜杠。例如。
$ cd /home/shum
$ pwd
/home/shum
$ cd /home//shum
$ pwd
/home/shum
$ cd /home///shum
$ pwd
/home/shum
然而由于某种原因，绝对路径开头的两个正斜杠被特殊对待。例如。
$ cd ////home
$ pwd
/home
$ cd ///
$ pwd
/
$ cd //
$ pwd
//
$ cd home//shum
$ pwd
//home/shum
补丁中任何其他地方的任何其他数量的连续正斜杠都会被截断，但开头的两个将保留，即使您随后在相对于它的文件系统中导航。
为什么是这样？/... 和 //... 之间有什么区别吗？
玩 e2fsprogs debugfs，由于更改/意外，filen/ame创建了一个名为的文件。显然，正斜杠字符/用作路径名中的特殊分隔符。
仍在使用debugfs我想删除名为 的文件filen/ame，但我没有成功，因为该/字符没有被解释为文件名的一部分？
debugfs 是否提供删除包含斜杠的文件的方法？如果是这样怎么办？
我用了：
cd /tmp
echo "content" > contentfile
dd if=/dev/zero of=/tmp/ext4fs bs=1M count=50
mkfs.ext4 /tmp/ext4fs
debugfs -w -R "write /tmp/contentfile filen/ame" /tmp/ext4fs
debugfs -w -R "ls" /tmp/ext4fs
输出：
debugfs 1.43.4 (31-Jan-2017)
2 (12) . 2 (12) .. 11 (20) lost+found 12 (980) filen/ame
我尝试了以下方法来删除filen/ame文件：
debugfs 1.43.4 (31-Jan-2017)
2 (12) . 2 (12) .. 11 (20) lost+found 12 (980) filen/ame
但这不起作用，只会产生：
debugfs …我刚刚在Unix Programming Environment，Kernighan 和 Pike 关于 Unix 的经典书籍中遇到了以下问题（我在 1984 年版第 79 页，ISBN：0-13-937699-2 中找到了以下文字）：
练习 3-6。（技巧问题）如何将 / 放入文件名（即，不分隔路径组成部分的 /？
作为最终用户和程序员，我多年来一直在使用 Linux，但我无法回答这个问题。有没有办法把斜线的文件名，这是绝对内核禁止。您可以通过块设备访问修补文件系统，或使用 Unicode 中外观相似的字符，但这些都不是解决方案。
我明白，Linux ？Unix，但同样的原则应该适用，因为系统必须能够明确地从路径中提取目录层次结构。
有人知道，Kernighan 和 Pike 在问这个问题时到底在想什么吗？假设的答案是什么？“套路”究竟是什么？或者也许原始的 Unix 系统只是允许以某种方式逃避这个斜线？
更新：
我就这个问题联系了 Brian Kernighan，他是这样回答的：
答案是（或曾经）“你不能。”
因此，蒂莫西·马丁是对的，得到了绿色的勾号。
我在这里有一个小问题。
如果我有两个文件，比如说filea和fileb，mv filea fileb会
filebfilea为fileb那么如果我有两个目录，比如说dira和dirb，mv dira dirb会
dira到dirb（会成为dirb/dira）注意到在这两种情况下都没有通知或消息，这对我来说非常不一致。我认为mv dira dirb应该只是简单地覆盖dirb与内容dira（或指定目录下的合并两个目录dirb）。
我记得在某处读到过，带斜杠的目录名（如dira/）被视为目录，而没有斜杠的名称（如dira）被视为文件（当然，在某种程度上）。无论如何，现在我想让 shell（zsh 和可能的 bash）通过使用斜杠来尊重我的目录符号。是否有一个终端选项可以让我强制执行？
澄清一下，这是我想要的行为：
mv dira dirb结果dirb被内容覆盖diramv dira dirb/结果dira被移入dirb（在dirb/dira）有没有人和我一样的想法？还是我只是奇怪？
我试图查看 O'Reilly 关于 Unix 和 Bash 的一些参考资料，*/但找不到任何参考资料。我们可以echo */看到所有的目录。
好像只表示所有“目录”，而*表示“所有文件和目录”，但不知为何，很多用户似乎不知道，书籍也没有提到。
是否有明确的来源谈论什么*/意味着及其变化？