入ると
cat > file.txt 2>&1
その後、標準入力の内容を使用してfile.txt生成されます。catしかし、私がそうするなら
cat > file.txt 1>&2
それからfile.txt作成されましたが、ファイルは空でした。
上記の2つのコマンドの問題は何ですか？
ベストアンサー1
順序が重要です。シェルはファイルリダイレクトを処理します。見る順に。 考慮する:
cat >file.txt 2>&1
まず、stdoutがファイルにリダイレクトされますfile.txt。次に、stderrはstdoutにリダイレクトされます。つまり、file.txtstdoutとstderrの両方がfile.txt。
これとは対照的に、次の点を考慮してください。
cat >file.txt 1>&2
まず、stdoutがファイルにリダイレクトされますfile.txt。 （これによりfile.txt空のファイルが生成されます。）次に、stdoutがstderrにリダイレクトされます。したがって、stdoutはstderrに移動しますが、内容がないため空のファイルのままですfile.txt。file.txt
もう一つの興味深い事例
考慮する:
cat 2>&1 >file.txt
まず、stderrはまだターミナルのstdoutにリダイレクトされます。次にstdoutはにリダイレクトされますfile.txt。 2番目のリダイレクトはstderrには影響しません。それでも端末に送信されます。これはいいえ発行されたfile.txt。
文書
この動作は次に文書化されていますman bash。
リダイレクトは、表示された順序で左から右に処理されます。
この順序の例外はパイプであり、また説明されていますman bash。考慮する:
command1 ... | command2
標準出力はcommand1パイプを介して標準入力に送信され、command2この接続を実行します。
今後最初のコマンドで指定されたすべてのリダイレクト。
パイプラインの例
考慮する:
command1 >file.txt | command2
リダイレクトがfile.txt発生するため後ろにパイプにリダイレクトされると、stdoutはcommand1に移動しますfile.txt。 command2入力は受信されません。