98

私はこの表現に少し混乱しました：

gcc -c -g program.c >& compiler.txt

&>filenamestdoutとstderrの両方をファイルにリダイレクトすることはわかっていますfilename。ただし、この場合、アンパサンドは大なり記号の後にあります。これは、の形式のように見えます。M>&Nここで、MおよびNはファイル記述子です。

上記のスニペットでは、doesM=1とN='compiler.txt'？これは次とどの程度正確に異なりますか。

gcc -c -g program.c > compiler.txt     (ampersand removed)

私の理解では、開いている各ファイルは2より大きいファイル記述子に関連付けられています。これは正しいですか？

もしそうなら、ファイル名はリダイレクトのターゲットとしてのファイル記述子と交換可能ですか？

4

2 に答える 2

111

これはと同じ&>です。bashのマンページから：

標準出力と標準エラーのリダイレクトこの構成により、標準出力（ファイル記述子1）と標準エラー出力（ファイル記述子2）の両方を、名前が単語の展開であるファイルにリダイレクトできます。

There are two formats for  redirecting  standard  output  and  standard
error:

       &>word
and
       >&word

Of the two forms, the first is preferred.  This is semantically equiva-
lent to

       >word 2>&1
于 2012-06-29T02:57:19.930 に答える
19

&>vs >&：推奨バージョンは&>（clobber）です

それにかんする：

  • &>
  • >&

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

ただし、bash手動のリダイレクトセクションでは次のように追加されます。

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

>word 2>&1

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

（注：どちらも同等ですzsh。）

&>最初の（ ）形式で指の記憶を取得することは非常に良い習慣です。理由は次のとおりです。

（追加）によってサポートされていないように&>>使用する>>&bash

追加フォームは1つだけです。

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

&>>word

これは意味的には同等です

>>word 2>&1

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

ノート：

  • に追加する方法が1つしかないため、上記のセクションでの&>overのclobberの使用を再度お勧めします。>&bash
  • zsh&>>と>>&フォームの両方を許可します。
于 2018-06-30T06:39:33.510 に答える