bashプロンプトを持つ2つのウィンドウ、同じユーザー。ウィンドウ-1に入力:
$ mkfifo f; exec <f
したがって、bashは名前付きパイプにマップされているファイル記述子0から読み取ろうとしますf。ウィンドウ2に次のように入力します。
$ echo ls > f
これで、window-1がlsを印刷し、シェルを終了します。なぜ？
次の実験：を使用してwindow-1を再度開きますexec <f。ウィンドウ2に次のように入力します。
$ exec 3>f
$ echo ls >&3
上記の最初の行の後にwindow-1が起動し、プロンプトを印刷します。なぜ？上記の2行目以降、window-1はls出力を印刷し、シェルはアクティブのままです。なぜ？実際、window-2ではecho ls > fwindow-1シェルは閉じられません。
答えは次のようにする必要があります存在するwindow-2のファイル記述子3は名前付きパイプを参照していますか？ ！
ベストアンサー1
これは以下に関連しています。閉鎖ファイル記述子。
最初の例では、echo標準出力ストリームに書き込むと、シェルはストリームに接続するためにストリームを開き、終了するとfその記述子がシェルによって閉じられます。受信側では、標準入力ストリーム（に接続されている）からf入力を読み取るシェルがを読み込み、ls実行し、ls標準入力のファイル終了条件のため終了します。
ファイル終了条件は、名前付きパイプのすべてのライター（この例では1つのみ）がそのパイプの終わりを閉じたために発生します。
2番目の例では、ファイル記述子3が書き込み用に開き、書き込み用にexec 3>f開きます。これで、コマンドではなくファイル記述子を開くシェルです。記述子は、この操作を実行するまで開いたままになります。受信側では、標準入力ストリーム（に接続されている）から入力を読み取るシェルが読み込み、実行してから追加の入力を待ちます（ストリームがまだ開いているため）。fecholsechoexec 3>&-flsls
すべての作成者（シェル、via exec 3>f、echoいいえパイプの端を閉じました（exec 3>fまだ有効です）。
echo上記をあたかも外部コマンドであるかのように作成しました。ケースに内蔵されている可能性が高いです。それでも効果は同じです。