web-dev-qa-db-ja.com

&>>&と2>&1のリダイレクトの違い

this SO thread およびその他のいくつかのスレッドで、stdoutおよびstderrをファイルにリダイレクトするための次のコマンドを見ました。

それらはすべて同等ですか?それらの間に違いはありますか?

command1 >> logfile 2>&1
command &> logfile
command >& logfile
12

zshをタグ付けしたので、3つのリダイレクトすべてがまったく同じように機能することをお知らせします。両方の重複した投稿(コメントの投稿と投稿の投稿の両方)を読んだことがあるかもしれませんが、それらはすべてstderrstdoutにリダイレクトし、次にファイル 'logfile'にリダイレクトされます(つまり、ログファイルには出力とエラーの両方が含まれます)。

しかし、彼らの行動はあなたがいるシェルに応じてLOTを変えます。

リダイレクトの3つのスタイルはすべて、bashzshで同じようにうまく機能します

しかし:

cshまたはtcshでは>&のみが機能します

[soum@server ~]$  ./test.sh > logfile 2>&1
Ambiguous output redirect.
[soum@server ~]$ ./test.sh &> logfile
Invalid null command.
[soum@server ~]$ ./test.sh >& logfile
[soum@server ~]$ echo $Shell
/bin/tcsh
[soum@server ~]$

kshでは2>&1のみが機能します。

$ ./test.sh >& logfile
-ksh: logfile: bad file unit number
$ ./test.sh &> logfile
[1]     23039
$ 1  2  3  4  5  6  logfile  test.sh
ls: cannot access ttr: No such file or directory

[1] +  Done(2)                 ./test.sh &> logfile

kshは嫌いです。 >&はエラーを表示しただけですが、&>はコマンドの一部をバックグラウンド化し、ログファイルを空にしました(空でない場合)。

7
Sree

&>>&の半同等性(クローバー)

zsh手動リダイレクトセクション は次のように述べています。

  • &>
  • >&

同等です。

どちらもファイルを上書きします-STDINのみの場合の> fileと同様に、ファイルに書き込む前にファイルを0バイトに切り捨てます。

ただしbash手動リダイレクトセクション は以下を追加します。

2つの形式のうち、最初の形式が優先されます。これは意味的には

>Word 2>&1

2番目の形式を使用する場合、Wordは数値または-に展開されない場合があります。その場合、互換性の理由から、他のリダイレクト演算子が適用されます(下記のファイル記述子の複製を参照)。

したがって、zshをタグ付けしている間は、bashスクリプトを記述した場合に、最初の形式でフィンガーメモリを取得することをお勧めします。

>> logfile 2>&1および&>>同等(追加)

ここでは、logfileは上書きされませんが、ファイルの最後に書き込むために開かれます。つまり、追加モード(O_APPEND)です。

両方の{ba,z}shで同等のものは次のとおりです。

command1 &>> logfile

bash内:

標準出力と標準エラーを追加する形式は次のとおりです。

&>>Word

これは意味的には

>>Word 2>&1

(下記のファイル記述子の複製を参照してください)。

(注:bashに追加する方法が1つしかないため、上記のセクションで&>よりも>&を使用することをお勧めします。)

zshでは、&>>>>&の両方の形式を使用できます。

1
Tom Hale