☰

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私を混乱させた。どのファイルがソースであるかわからない場合、forの代わりにそのファイルがrealpath表示されるのはなぜですか？/usr/bin/pip/bin/pip/bin/pip

私はその1つが次の理由でハードリンクである可能性があることを知っています。

$ 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へのシンボリックリンクです。

$ 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

両方のディレクトリエントリが同じinode /ファイルを参照しているか（直接的または間接的に）再確認する必要があります。

今試してください：

ls -ld /bin /usr/bin

これにより、両方のディレクトリ（d最初の列）が表示されます。そのうちの1つ（ほぼ確実に）がその列に表示/usr/binされる場合l、これはシンボリックリンクであり、これは現在見ている動作を説明します（realpath前述のシンボリックリンクの解決）。

最後の説明：どちらか一方が他方へ/binの/usr/binシンボリックリンクである場合、realpathシンボリックリンクはターゲットに移動し、そのターゲットを実際のパスとして使用します。

GNU realpath（他のすべてではない）にはこの--no-symlinksオプションがあります。これにより、もともと期待していた結果が得られます。

関連情報