I agree. zgrep also works for uncompressed files, so we could use e.g. zgrep ^ instead of zcat.
this post was submitted on 18 Dec 2024
43 points (100.0% liked)
Linux
1261 readers
27 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
Thanks, didn't know that existed
That's basically everything I was looking for !
Yeah, it's a pain. Leads to bad one liners:
for i in $(ls); do zcat $i || cat $i; done
Btw, don't parse ls. Use find |while read -r instead.
find -maxdepth 1 -name "term" -print |while read -r file
do zcat "$file" 2>/dev/null || cat "$file"
done
Won't this cause cat to iterate through all files in the cwd once zcat encounters an issue, instead of just the specific file?
Yeah, i was tired and had $file there first, then saw that you wanted to cat all in directory. Still tired, but i think this works now.
You can just do for f in * (or other shell glob), unless you need find's fancy search/filtering features.
The shell glob isn't just simpler, but also more robust, because it works also when the filename contains a newline; find .. | while read -r will crap out on that. Also apparently you want while IFS= read -r because otherwise read might trim whitespace.
If you want to avoid that problem with the newline and still use find, you can use find -exec or find -print0 .. | xargs -0, or find -print0 .. | while IFS= read -r -d ''. I think -print0 is not standard POSIX though.
because it works also when the filename contains a newline
Doesn't that depend on the shell?
I don't think so and have never heard that, but I could be wrong.
Thanks !
But still we shouldn't have to resort to this !
~~Also, can't get the output through pipe~~
for i in $(ls); do zcat $i || cat $i; done | grep mysearchterm
~~this appears to work~~
~~find . -type f -print0 | xargs -0 -I{} sh -c 'zcat "{}" 2>/dev/null || cat "{}"' | grep "mysearchterm"~~
~~Still, that was a speed bump that I guess everyone dealing with mass compressed log files has to figure out on the fly because zcat can't read uncompressed files ! argg !!!~~
for i in $(ls); do zcat $i 2>/dev/null || cat $i; done | grep mysearchterm
How do you propose zcat tell the difference between an uncompressed file and a corrupted compressed file? Or are you saying if it doesn't recognize it as compressed, just dump the source file regardless? Because that could be annoying.
Even a corrupt compressed files has a very different structure relative to plain text. "file" already has the code to detect exactly which.
Still, failing on corrupted compression instead of failing on plaintext would be an improvement.
What even is plain text anymore? If you mean ASCII, ok, but that leaves out a lot. Should it include a minimal utf-8 detector? Utf-16? The latest goofy encoding? Should zcat duplicate the functionality of file? Generally, unix-like commands do one thing, and do it well, combining multiple functions is frowned upon.
I wouldn't call all this hoop jumping to reading common log files "doing it better".
This is exactly the kind of arcane tinkering that makes everything a tedious time wasting chore on linux.
At this point it's accepted that text files get zipped and that should be handled transparently and not be precious about kilobits of logic storage as if we were still stuck on a 80386 with 4 megs of ram.
just use -f lol.
less $(which zcat) shows us a gzip wrapper. So we look through gzip options and see:
-f --force
Force compression or decompression. If the input data is not in a format recognized by gzip, and if the option --stdout is also given, copy the input data without change to the standard output: let zcat behave as cat.
party music
That works great now I can zcat -f /var/log/apache2/*
Celeste. Are you here? In a future search maybe?