Bash：ファイル記述子のリダイレクト

Question

誰かが現象を説明することができると考えています。タイトルが示すように、私はファイル記述子のリダイレクトについて学習しています。途中で、リダイレクト記号の使用を取り巻く問題、特に永続的なリダイレクトを設定するときに、私は質問に出くわしました。私は、特定のケースでは、<と>のどちらを使用するかは問題ではないようです。たとえば、次のスクリプトでの作業：私の驚きに

#!/bin/bash 

#Setting file descriptor 3 to redirect to STDIN 
exec 3<&0 

#Setting STDIN to read from input file 
exec 0<inputFile 


while read var 
do 
    echo "$var" 

done 

#Setting STDIN to read from file descriptor 3 which is redirected to the default STDIN 
exec 0<&3 

read -p "Enter a word:" word 

echo "$word" 

が、私が文exec 3<&0またはexec 0<&3に>か<を使用している場合は関係していないようです。これらのステートメントのいずれかで、リダイレクトシンボルを交換すると、まったく同じ結果が得られるようです。それは私には明白なようで、その行への変更の同じ種類を作る：

exec 0<inputFile 

対

exec 0>inputFile 

ファイルにSTDINをリダイレクトすると、同じものではありませんので、同じ結果が得られませんファイルをSTDINにリダイレクトします。

だから私の質問は以下のとおりです。>対

1. <：

   0<&3対

   # Why aren't there any differences between these two statements? 
   exec 3<&0 
   exec 3>&0 
   

2. 3<&0：

   # Why is there a difference between these two statements? 
   exec 3<&0 
   exec 0<&3 
   

このタイプのリダイレクトは、私の頭を包み込み、これらのタイプの不一致なしにまっすぐに保つのに十分なほど難しいです。すべての説明は非常に高く評価されます。

Answer 1

ときファイル記述子を複製し、それは問題ではない、dup2が呼び出され、あなたが<や>を使用している場合に関係なく。

ファイル記述子を閉じるときも同じことが起こります。 n>&-またはn<&-を使用できます。

---

しかし、なぜ、その後3<&0と0<&3同じものではありませんか？引数がある

[EBADF]

fildesで：私はリンクdup2仕様で説明しています

は、次の場合

int dup2(int fildes, int fildes2); 

dup2の（）関数は失敗するもの有効なオープンファイル記述子または引数ではありませんfildes2は負または{OPEN_MAX}以上です。exec 0<&3の場合

、bashはdup2(3,0)を呼び出し、実際に（その時点で有効なオープンファイル記述子ではありません、我々は場合にしているので、fildesで = 3）EBADFエラーを受け取ります。

$ strace -e dup2 bash -c 'exec 0>&3' 
dup2(3, 0)        = -1 EBADF (Bad file descriptor) 
bash: 3: Bad file descriptor 
dup2(10, 0)        = 0 
+++ exited with 1 +++