何らかの理由でSSHからsedにコマンド出力をパイプするときは、ライブ出力はありません。
ssh someuser@somehost 2>&1 | sed -e "s/\[32//g" | tee logging
出力ditに改行文字がないようですが、sedコマンドを削除して実行すると、次のようになります。
wc -l logging
返す正しい数値である6を返します。私がここで何を見逃しているのか知っている人はいますか？
[編集] 以下のことを言及することを完全に忘れてしまいました。実行中
ssh someuser@somehost 2>&1 | sed -e "s/\[32//g"
すべての値は問題なく返されますが、一度ミックスにteeを追加すると、^ Cを押すまで出力が得られません... stdoutリダイレクトも機能しません（ssh someuser@somehost 2>&1 | 32//g"> ファイル)。 sshとteeだけがうまくいきます。
答え1
ストリームエディタ、sed、バッファ、「-u」、または「--unbuffered」で無効になります。
tail -f some/log_file | sed -u 's/foo//g' | grep bar
答え2
明示的なコマンドなしで実行すると、ssh user@somehostリモートシステムで対話型シェルを起動するようにsshを要求します。
bashのような対話型シェルはしばしば端末コマンドラインと検索履歴を編集するときに環境を改善するためにターミナルコマンドを使用するため、使用できます。 (ターミナルコマンドでフルスクリーン制御が可能です.)
ただし、sshはデフォルトで端末（または端末）のみを割り当てます。擬似端末) 標準出力が端子に接続されている場合。
ターミナルプログラム（例：gnome-terminal、rxvt、xtermなど）で実行している場合、標準出力はターミナルであるため、ssh user@somehostsshは擬似ターミナルを生成し、リモートインタラクティブシェルは正常に動作します。
たとえば、何かを介してsshをパイプすると、標準出力はパイプssh user@somehost | cat（ターミナルではない）になるため、sshは端末を生成しないため、リモート対話型シェルが異常に機能する可能性があります。
考えられる解決策の1つは、optionsを渡してsshに擬似端末を作成させることです-t。ssh -t user@somehost | cat可能助ける。 （また、-tt疑似端末を強制的に割り当てるには、デュアルオプションが必要な場合があります。）
もう1つの可能性は、特定のコマンドに興味があるため、主にsshを実行している場合は、sshコマンドラインから特定のコマンドを実行できることですssh user@somehost mycommand | cat。たとえば、特定のコマンドを実行すると、関連する対話型シェルはありません。この場合、動作する端末があると問題が発生しない可能性があります。
答え3
同じコマンドを使用して、次を追加しましょう。
ssh someuser@somehost 2>&1 | sed -e "s/\[32//g" | tee --output-error=warn logging
これにより、標準出力に書き込むときにエラーがないかどうかを確認できます。これが役立つ場合は教えてください。
見積もりをインストールして試すことができます。
unbuffer ssh someuser@somehost 2>&1 | sed -e "s/\[32//g" | tee logging