GNU bug report logs -
#42402
Enhancement request re zcat with empty files
Previous Next
Reported by: Peter Horn <peter.horn <at> bigpond.com>
Date: Fri, 17 Jul 2020 04:37:02 UTC
Severity: wishlist
Done: Paul Eggert <eggert <at> cs.ucla.edu>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 42402 in the body.
You can then email your comments to 42402 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gzip <at> gnu.org
:
bug#42402
; Package
gzip
.
(Fri, 17 Jul 2020 04:37:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Peter Horn <peter.horn <at> bigpond.com>
:
New bug report received and forwarded. Copy sent to
bug-gzip <at> gnu.org
.
(Fri, 17 Jul 2020 04:37:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hello list,
This is my first post here, so apologies in advance for whatever I get
wrong.
I am asking for an enhancement to zcat, that it should silently ignore
empty files, either always, or (if that conflicts with POSIX or some
other standard), by a command line option.
My use case is as follows:
I maintain a server, and have occasion to scan log files for specific items.
As is typical in a logrotate environment, the files are something like
xyz.log current
xyz.log.1 previous
xyz.log.2.gz
xyz.log.3.gz etc etc
Most of the time I can search for something by
zgrep 'target' xyz*
But, wanting to further process a number of entries, I tried the obvious
zcat xyz* | awk ...
which results in
gzip: xyz.log.1: unexpected end of file
I note that it correctly handles archives with no content (just the 20
byte header)
Regards,
Peter
Information forwarded
to
bug-gzip <at> gnu.org
:
bug#42402
; Package
gzip
.
(Sat, 18 Jul 2020 05:46:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 42402 <at> debbugs.gnu.org (full text, mbox):
Peter Horn wrote:
> But, wanting to further process a number of entries, I tried the obvious
> zcat xyz* | awk ...
> which results in
> gzip: xyz.log.1: unexpected end of file
To perhaps help work around the issue you have raised I'll just
suggest that 'zmore' and 'zless' can be (ab)used in this case. They
are both the same. And also though you mentioned 'zgrep' it can also
be used early in the pipeline. Try it this way.
zmore xyz.log* | awk ...
zless xyz.log* | awk ...
zgrep whatever xyz.log* | awk ...
It's somewhat backing into the solution but perhaps useful for you in
the toolbox regardless.
Bob
Reply sent
to
Paul Eggert <eggert <at> cs.ucla.edu>
:
You have taken responsibility.
(Thu, 07 Apr 2022 00:09:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Peter Horn <peter.horn <at> bigpond.com>
:
bug acknowledged by developer.
(Thu, 07 Apr 2022 00:09:02 GMT)
Full text and
rfc822 format available.
Message #13 received at 42402-done <at> debbugs.gnu.org (full text, mbox):
> I am asking for an enhancement to zcat, that it should silently ignore
> empty files, either always, or (if that conflicts with POSIX or some
> other standard), by a command line option.
zcat -f does what you're asking for. For example:
$ touch empty
$ echo something | gzip >abc.gz
$ zcat -f *
something
Since the -f option satisfies your request I'll close the bug report.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Thu, 05 May 2022 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 96 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.