バッシュから。
何を使うべきかを理解するのに問題がありますか？
私のすべてのスクリプトは ">>/dev/stderr" を使用します。
bashプロンプトで試した場合：
echo test >>/dev/stderr有効な
echo test >> /dev/stderr有効
echo test >/dev/stderrな有効
echo test > /dev/stderr
echo test >>&2失敗しました！
echo test >> &2失敗しました！
echo test >&2ジョブが
echo test > &2失敗しました！
すべてのスクリプト>&2を 。
また、まったく機能せず（権限が拒否されました）、操作のみのssh（後で）にsu SomeUser大きな影響を与えるようです。>>/dev/stderr>&2
ベストアンサー1
>& nシェル構文は次のとおりです。ファイル記述子を直接コピー。ファイル記述子2はstderrです。これがうまくいく方法です。 stderrだけでなく、他のファイル記述子をコピーすることもできます。コピーファイル記述子が切り捨てられず（stderrがファイルの場合でも）トークンである>&ため、ここでは追加モードを使用できません。したがって、スペースを入れることはできませんが、>& 2動作します。
>> nameは許可される他の構文です。ここで、はnameファイル名です（トークンは>>）。この場合、/dev/stderrオペレーティングシステム固有の処理では、標準エラーに対応するファイル名を使用しています（Linuxではシンボリックリンク/proc/self/fd/2）。 stderrが端末の場合、追加モードとトリミングモードの両方が同じことを行います。なぜなら、切り取ることができないからです。ただし、標準エラーがファイルの場合〜する切り捨て：
anthony@Zia:~$ bash -c 'echo hi >/dev/stderr; echo bye >/dev/stderr' 2>/tmp/foo
anthony@Zia:~$ cat /tmp/foo
bye
sshでエラーが表示された場合は、/dev/stderrサーバー管理者がシンボリックリンクの操作を防ぐいくつかのセキュリティ対策を適用した可能性があります。 （例：/procまたはにアクセスできません/dev）。どちらのアプローチも、あらゆる種類の奇妙な破損を引き起こすと予想していますが、冗長ファイル記述子構文を使用するのは完全に合理的で、おそらくやや効率的なアプローチです。私は個人的にそれを好む。