パイプのバッファリングをオフにします

2つのコマンドを呼び出すスクリプトがあります。

long_running_command | print_progress

long_running_commandプリントは進歩が、私はそれに不満です。print_progressより良いものにするために使用しています（つまり、進行状況を1行で出力します）。

問題：stdoutにパイプを接続すると、4Kバッファーもアクティブになります。素敵な印刷プログラムには何も...何も...何も... たくさんありません... :)

4Kバッファーを無効にするにはどうすればよいですかlong_running_command（いいえ、ソースがありません）？

unbufferコマンド（expectパッケージの一部として提供されます）を使用できます。例えば

unbuffer long_running_command | print_progress

unbufferlong_running_command疑似端末（pty）を介して接続します。これにより、システムはそれを対話型プロセスとして扱い、パイプラインで4-kiBバッファリングを使用せず、遅延の原因となる可能性があります。

より長いパイプラインの場合、各コマンドのバッファリングを解除する必要がある場合があります（最後のコマンドを除く）。

unbuffer x | unbuffer -p y | z

この猫の皮を剥ぐ別の方法stdbufは、GNU Coreutilsの一部であるプログラムを使用することです（FreeBSDにも独自のプログラムがあります）。

stdbuf -i0 -o0 -e0 command

これにより、入力、出力、エラーのバッファリングが完全にオフになります。アプリケーションによっては、パフォーマンス上の理由から、ラインバッファリングの方が適している場合があります。

stdbuf -oL -eL command

_{動的にリンクされたアプリケーションのstdioバッファリング（printf()、fputs()...）に対してのみ機能し、そのアプリケーションが標準ストリームのバッファリングをそれ以外の方法で調整しない場合にのみ機能することに注意してください。}

の行バッファリング出力モードをオンにするもう1つの方法は、疑似端末（pty）で実行するコマンドlong_running_commandを使用するscriptことlong_running_commandです。

script -q /dev/null long_running_command | print_progress      # FreeBSD, Mac OS X
script -c "long_running_command" /dev/null | print_progress    # Linux

以下のためにgrep、sedそしてawkあなたはラインバッファリングする出力を強制することができます。次を使用できます。

grep --line-buffered

出力を強制的に行バッファリングします。デフォルトでは、標準出力が端末である場合、出力は行バッファリングされ、それ以外の場合はブロックバッファリングされます。

sed -u

出力行をバッファリングします。

詳細については、このページを参照してください：http : //www.perkin.org.uk/posts/how-to-fix-stdio-buffering.html

出力が端末に送られないときにlibcがバッファリング/フラッシュを変更することに問題がある場合は、socatを試してください。ほぼすべての種類のI / Oメカニズム間で双方向ストリームを作成できます。それらの1つは、疑似ttyに話す分岐プログラムです。

 socat EXEC:long_running_command,pty,ctty STDIO 

それは何ですか

• 擬似ttyを作成します
• stty / stdoutとしてptyのスレーブ側でlong_running_commandをフォークします
• ptyのマスター側と2番目のアドレス（ここではSTDIO）の間に双方向ストリームを確立します

これにより、と同じ出力が得られる場合はlong_running_command、パイプで続行できます。

編集：すごいアンバッファーの答えが表示されませんでした！とにかく、socatはとにかく素晴らしいツールなので、この答えをそのままにしておくかもしれません

使用できます

long_running_command 1>&2 |& print_progress

問題は、スクリーンへの標準出力時にlibcがラインバッファし、ファイルへの標準出力時にフルバッファすることです。しかし、stderrにはバッファがありません。

パイプバッファの問題ではないと思います。libcのバッファポリシーがすべてです。

標準出力が端末に書き込まれると、デフォルトで行バッファリングされます-改行が書き込まれると、行は端末に書き込まれます。標準出力がパイプに送信されると、完全にバッファリングされます。したがって、データは、標準I / Oバッファがいっぱいになるとパイプラインの次のプロセスにのみ送信されます。

それが問題の原因です。パイプに書き込むプログラムを変更せずに修正するためにできることがたくさんあるかどうかはわかりません。フラグsetvbuf()付きの関数を使用して、_IOLBF無条件stdoutに行バッファーモードにできます。しかし、プログラムでそれを強制する簡単な方法は見当たりません。または、プログラムはfflush()適切なポイント（出力の各行の後）で実行できますが、同じコメントが適用されます。

パイプを擬似端末に置き換えた場合、標準I / Oライブラリは出力が端末であると見なし（端末の一種であるため）、ラインバッファを自動的に処理すると考えられます。しかし、それは物事を処理する複雑な方法です。

これは古い質問であり、すでに多くの回答がありましたが、バッファの問題を回避したい場合は、次のようなものを試してください：

stdbuf -oL tail -f /var/log/messages | tee -a /home/your_user_here/logs.txt

これにより、ログがリアルタイムで出力され、ログがlogs.txtファイルに保存され、バッファはtail -fコマンドに影響を与えなくなります。

問題はパイプにあるとは思わない。長時間実行しているプロセスが自身のバッファを十分な頻度でフラッシュしていないようです。パイプのバッファーサイズを変更することは、それを回避するためのハックになりますが、カーネルを再構築しないとその可能性はないと思います。

ここのこの投稿によると、パイプのulimitを1つの512バイトブロックに減らすことができます。それは確かにバッファリングをオフにしませんが、まあ、512バイトは4Kよりもはるかに少ないです：3

chadの答えと同様に、次のような小さなスクリプトを書くことができます。

# save as ~/bin/scriptee, or so
script -q /dev/null sh -c 'exec cat > /dev/null'

次に、このscripteeコマンドをの代わりとして使用しteeます。

my-long-running-command | scriptee

残念ながら、そのようなバージョンをLinuxで完全に動作させることはできないので、BSDスタイルのUNIXに限定されているようです。

Linuxでは、これは近いですが、（Enterキーを押すまでなど）終了してもプロンプトは返されません...

script -q -c 'cat > /proc/self/fd/1' /dev/null

私はこの賢い解決策を見つけました： (echo -e "cmd 1\ncmd 2" && cat) | ./shell_executable

これがトリックです。cat（EOFまで）追加の​​入力を読み取りecho、の入力ストリームに引数を入力した後、それをパイプに渡しshell_executableます。

よると、このパイプのバッファサイズはカーネルに設定されているように見えると変えるためにあなたのカーネルを再コンパイルする必要がありません。