I have a job on a batch system that runs extremely long and produces tons of output. So much actually that I have to pipe the standard output through gzip to keep the batch node from filling its work area and subsequently crashing.
longscript | gzip -9 > log.gz
Now, I would like to investigate the output of the job while it is still running. So I do this:
gunzip log.gz
This runs very long, as it is huge file (several GB). I can see the output file being created while it is running and can look at it while it is being built.
tail log
> some-line-of-the-log-file
tail log
> some-other-line-of-the-log-file
However, ultimately, gzip encounters the end of the gzipped file. Since the job is still running and gzip is still writing the file, there is no proper footer yet, so this happens:
gzip: log.gz: unexpected end of file
After this, the extracted log file is deleted, as gzip thinks that the corrupted extracted data is of no use to me. I, however, disagree - even if the last couple of lines are scrambled, the output is still highly interesting to me.
How can I convince gzip to let me keep the "corrupted" file?
gunzip -c
writes output to stdout...maybe that's what you are looking for? It keeps original unchanged. – bretonics Apr 12 '17 at 15:45