
実行しようとしています。
tail -100000f MXMLExchangeMonitoring_Mx3.log | egrep "INTENTO.*Workflow" | cut -d ":" -f "3" | cut -c 3,4,5,6 | awk '{if($1>20)print$1}'
私は何も得られませんでした。
しかし、一緒に
tail -100000 MXMLExchangeMonitoring_Mx3.log | egrep "INTENTO.*Workflow" | cut -d ":" -f "3" | cut -c 3,4,5,6 | awk '{if($1>20)print$1}'
期待される結果を得る。
212
45
29
463
544
556
543
1115
830
802
119
95
33
31
194
170
127
97
-f
ファイルに表示される20より大きい新しい数字を読むには、この情報が必要です。
行数を減らすこともオプションです。 -100のような少量で始めることができます。
このtail -f
作品は以下に適しています:
tail -100000f MXMLExchangeMonitoring_Mx3.log | egrep "INTENTO.*Workflow" | cut -d ":" -f "3"
答え1
命じる標準出力fwrite()
端末(ここでパイプの前のコマンド)には、チャンク(別名全体)バッファリングを実行するstdio C関数(例:)がありません。以下は、動作の説明です。setvbuf(3)
(これは標準Cです。POSIX機能ですが、説明はGNUバリアントに従いました。POSIX正確な動作が定義された実装であることを示します。
通常すべてのファイルはブロックバッファリングされます。。ストリーム 端末(例:標準出力通常はそうです。)ラインバッファリングされます。。標準エラーストリーム標準エラーデフォルトは常にバッファリングなしです。
最後のコマンドを除く一連のパイプ内のすべてのコマンドが影響を受ける可能性があります。出力をバッファリングする通常の動作を取得します。
これは少なくともLinuxとFreeBSDで動作します。
いくつかのコマンド(
tail
)は「予想」のとおりに動作します。することはありません。
other(
grep
) にはオプションがあります。GNU および *BSD (さらには Mac OS X) の場合、動作を変更する
grep
組み込みオプションがあります。--line-buffered
その他(
cut
) はそうではありません。回避策があります。おそらくシステムによって異なります。GNUおよびFreeBSDシステム用のlibcラッパーがあります(しかし他の* BSDバリアントではないようです)。
stdbuf
目的は次のとおりです。tail -f access.log | stdbuf -oL cut -d ' ' -f1 | uniq
これにより、access.logの唯一のエントリがすぐに表示されます。
awk
パイプの終わりにあり、端末に出力されるため、影響を受けません(つまり、すでにラインバッファリングされています)。後で必要な場合、このツールには
fflush()
同じ効果を得るためのコマンドが含まれています。
これらの動的にリンクされたツールはすべて一部の特殊機能を使用せずにサポートする必要がありますstdbuf -o L
が、可能であればlibcラッパーを使用しないことをお勧めします。
これらすべてを念頭に置いてstdbuf
インストールされたら、この修正された行は期待どおりに実行する必要があります(読みやすくするために複数行に分割しました)。
tail -100000f MXMLExchangeMonitoring_Mx3.log |
egrep --line-buffered "INTENTO.*Workflow" |
stdbuf -o L cut -d ":" -f "3" |
stdbuf -o L cut -c 3,4,5,6 |
awk '{if($1>20)print$1}'
いくつかの単純なフィルタリングでは、動作を簡単に変更できないコマンド(最後のコマンドのように)だけを維持するようにコマンドの順序を変更するだけで十分です。ただし、そうでない場合は、パイプラインにstdbuf
2つある場合でもcut
問題は解決しません。