私は非常に長い時間実行され、多くの出力を生成するバッチシステムで作業しています。バッチノードがワークスペースでいっぱいになった後にクラッシュするのを防ぐには、実際にgzipを介してstdoutをパイプする必要があります。
longscript | gzip -9 > log.gz
さて、ジョブの実行中に出力を調べたいと思います。だから私はこうします：
gunzip log.gz
大容量ファイル（数GB）なので、実行に時間がかかります。出力ファイルが実行時に生成されるのを見ることができ、ビルド時に見ることができます。
tail log
> some-line-of-the-log-file
tail log
> some-other-line-of-the-log-file
しかし、最終的にgzipはgzip圧縮ファイルの終わりに出会います。これは、ジョブがまだ実行中であり、gzipがまだファイルに書き込んでいるために発生するため、まだ正しいフッターがありません。
gzip: log.gz: unexpected end of file
その後、抽出されたログファイルが削除されます。 gzipは、破損した抽出データが私に役に立たないと考えているためです。しかし、私はこれに同意しません。最後の数行が混在していても、出力は依然として非常に興味深いでしょう。
「破損した」ファイルを維持するためにgzipをどのように説得できますか？
ベストアンサー1
ファイルの最後の部分に加えて、zcat（またはgzip -dc、または）を使用してgunzip -c圧縮されていないデータを表示できます。
zcat log.gz | tail
または
zcat log.gz | less
または
zless log.gz
gzipバッファリングは明らかな理由で発生します（データをチャンクに圧縮する必要があります）。したがって、プログラムが一部のデータを出力しても、そのデータがまだファイルに存在しない可能性がありますlog.gz。
圧縮されていないログを次のように保存することもできます。
zcat log.gz > log
...しかし、それは愚かなことです。当初、出力を圧縮する理由が明らかにあるからです。