☰

Coreutils realpath：与硬（？）链接一起使用时令人困惑的输出

tag-icon • tag-icon coreutils
Coreutils realpath：与硬（？）链接一起使用时令人困惑的输出

我正在“玩耍”并弄乱了 pip（Python 包管理器）的安装。无论如何，事实证明，在我的系统中/bin/pip是（？）的硬链接/usr/bin/pip（或者相反，因为我被告知硬链接不知道哪个文件是原始文件）。

$ realpath /bin/pip /usr/bin/pip
/usr/bin/pip
/usr/bin/pip

结果realpath让我很困惑。如果不知道哪个文件是原始文件，为什么会realpath显示/usr/bin/pip而不是/bin/pipfor /bin/pip？

我知道其中一个可能是硬链接，因为：

$ stat -c "%n is a %F pointing to inode %i, which has %h hard link(s)" /bin/pip /usr/bin/pip
/bin/pip is a regular file pointing to inode 152837, which has 1 hard link(s)
/usr/bin/pip is a regular file pointing to inode 152837, which has 1 hard link(s)

以防万一，我的机器运行的是 CentOS 7，我的 realpath 命令来自 GNU coreutils 8.22。

- - - - 编辑 - - - -

事实上，/bin 是指向 /usr/bin 的符号链接，而 /usr/bin 是常规目录：

$ ls -ld /bin /usr/bin
lrwxrwxrwx. 1 root root     7 May 15 12:49 /bin -> usr/bin
dr-xr-xr-x. 2 root root 53248 Jul 13 18:44 /usr/bin

答案1

我已经测试过这一点，但它不会发生在我身上。我怀疑（如建议的那样）这是由于某个地方的符号链接造成的，因为realpath解决了这些问题。

尝试：

ls -li /bin/pip /usr/bin/pip

这应该仔细检查两个目录条目是否引用相同的索引节点/文件（直接或间接）。

现在尝试：

ls -ld /bin /usr/bin

这应该显示两个目录（d在第一列中）。如果其中之一（几乎可以肯定在该列中/usr/bin显示l，那么它是一个符号链接，这将解释您所看到的行为（如前所述，realpath解析符号链接）。

最后澄清：如果其中一个/bin或/usr/bin是另一个的符号链接，则将realpath遵循符号链接到达其目标，并且它将使用该目标作为真实路径。

GNU realpath（但不是所有其他）有这个--no-symlinks选择；如果你使用它，你可能会得到你最初期望的结果。

相关内容