☰

Linuxのシンボリックリンクディレクトリにある「..」が「無効な」ディレクトリを参照するのはなぜですか？ [コピー]

tag-icon • tag-icon bash symlink
Linuxのシンボリックリンクディレクトリにある「..」が「無効な」ディレクトリを参照するのはなぜですか？ [コピー]

次のスクリプトを実行してみてください。

#!/bin/bash
mkdir a
mkdir a/asub
mkdir b
ln -sfr a/asub b/bsub
touch a/this_file_is_in_a
touch b/this_file_is_in_b
cd b/bsub
echo "I'm in directory: $(pwd)"
echo This is the contents of the upper directory:
ls ..

あなたは何を得ることを願っていますか？おそらくディレクトリの内容でしょうb。しかしそうではありません。私はそれをディレクトリで実行しました/tmp/bb。

結果は次のとおりです。

wzab@WZabHP:/tmp/bb$ ./ls_tester.sh
I'm in directory: /tmp/bb/b/bsub
This is the contents of the upper directory:
asub  this_file_is_in_a

したがって、pwd返される正しいパスはサブbディレクトリですが、「..」はサブディレクトリを表しますa。シンボリックリンクの私の理解は間違っていますか、それともLinuxのバグですか？

ベストアンサー1

考えると目次小さなファイルとして、基本的にリストまたはテーブルです。

ディレクトリが親ディレクトリを「知っている」理由は、ディレクトリ全体が背後で使用されるためです。便宜上、各ディレクトリには親ディレクトリと現在のディレクトリへのリンクがあります。

ディレクトリへのシンボリックリンクはファイルへのリンクと同じです。そのリンクされたディレクトリ「内部」にある場合は、そのリンクされたディレクトリにあり、親ディレクトリと現在の（実際の）ディレクトリへのハードリンク..です.。つまり、対応するシンボリックリンク（または任意のシンボルリンク）を「通過」します。情報は「得られた」」は技術的に失われた。

これら3つのハードリンクは、少なくともUnixoidalシステムでは、新しいディレクトリが作成されたときに常に作成されます（一部の古いUniceはランダムハードリンクを許可しますが）。

しかし、、皮には「便利な砂糖」がたくさん含まれています。シェルはこれをあなたのために覚えています実際にあなたはシンボリックリンクから来て、関連ディレクトリを「再接続」します。

シェルの組み込み機能pwdもこれを知っており、このように動作します。アプリケーションは/usr/bin/pwd単に正規化されたパスを宣言します。つまり、シンボリックリンクを介していません。そうでない場合は、そのディレクトリにアクセスできる方法はさまざまであり、技術的にこれらのすべての組み合わせ（循環シンボリックリンクがある場合は無限になる可能性があります）を印刷する必要があります。

ほとんどのシェルコマンドには、シンボリックリンクを介してディレクトリに入るときにシンボリックリンクに従うのではなく、物理ディレクトリ構造を使用するcdオプションがあります。-Pすることができます"bash_buildins"のマニュアルページman cd（内部から簡単にアクセス可能bash）

以下は抜粋ですman zshbuiltins。

-P オプションを指定するか、CHASE_LINKS オプションを設定すると、シンボリックリンクが実際の値としてチェックされます。 -L オプションを指定した場合、CHASE_LINKS オプションの状態に関係なく、シンボリックリンクはディレクトリに残り、確認されません。

（bashのマニュアルページにも同様のセクションが含まれています）

一度見てみたいかもしれません本物最小のエンクロージャ（例：s。日常のシェルとして使用する必要があることを示唆しているわけではありませんが、小さすぎて、コマンドソルバーが実際に提供する絶対に基本的な機能に加えて、多くのオペレーティングシステムツールに依存しています。その点で、この本はとても良い教育ツールです。

おすすめ記事