Mary via Bug reports for GNU grep writes:
> Dale R. Worley wor...@alum.mit.edu wrote:
>> [...]
> I already have a patch that I believe is trivial enough to not cause
> copyright concerns, would you like me to send it?
*I* am all in favor of it, but I'm not a grep maintainer!
Dale
Dale R. Worley wor...@alum.mit.edu wrote:
> I missed those facts. I only skimmed the section of
> http://www.nongnu.org/zutils/manual/zutils_manual.html about Zcat and
> hadn't read the "Common options" section which makes those clear. I'll
> have to remember that zcat has this nice functionality.
Antonio Diaz Diaz writes:
> Dale R. Worley wrote:
>> So the construction I'm thinking of would be
>>
>> grep ... --use-compress-program=zcat ... pattern file ...
> Zcat does indeed accept (and ignore) option -d for compatibility with gzip.
> Therefore all that is needed is to implement a
Dale R. Worley wrote:
So the construction I'm thinking of would be
grep ... --use-compress-program=zcat ... pattern file ...
Ah! interesting.
Zgrep duplicates some of the work of grep. For example it recurses through
directories, feeds grep one file at a time, and prepends the file
Antonio Diaz Diaz writes:
> Dale R. Worley wrote:
>> What doesn't seem to exist is something that does step 2 in a general
>> way. The tool that is needed is something that reads the first few
>> bytes of a file, determines which compression signature is present if
>> any, then processes the
> For a while, new options were getting added to GNU tar frequently in order
> to allow you to do things like
>
> compress -dc | tar xf -
> zcat | tar xf -
> bzcat | tar xf -
> lzcat | tar xf -
>
> etc., but just using the single tar invocation without (explicitly
> running) an external
Dale R. Worley wrote:
What doesn't seem to exist is something that does step 2 in a general
way. The tool that is needed is something that reads the first few
bytes of a file, determines which compression signature is present if
any, then processes the contents through the correct decompressor.
Dale R. Worley writes:
> What doesn't seem to exist is something that does step 2 in a general
> way. The tool that is needed is something that reads the first few
> bytes of a file, determines which compression signature is present if
> any, then processes the contents through the correct
People have mentioned that it's best for a utility "to do one thing
well". It seems to me that even the existing grep options do three
things (in the complex use cases):
- select a set of files
- uncompress the files (if they're compressed)
- search within the file contents
I am ignoring the
> Do you know zgrep from zutils?
TIL! My system does not come with those by default, and instead provides a
`zgrep` that is a Bash script supporting only `gzip`.
Are those the generally recommended tools to use? (I'm not sure why
`zgrep`/`bzgrep`/`xzgrep` would be provided by their respective
Shell scripting can take file names in from a find or ls with 'while read', or
by globbing 'for f in pattern', and examine them one by one, run 'grep -q' to
find out if the file or uncompressed stream from that file has a match, and if
so 'echo' the file name out, or if you want lines, it can
Paul Eggert wrote:
> I have some qualms though, as the new option would increase the attack
> surface for 'grep',
Agreed.
Given the recent uproar involving liblzma being linked into ssh in systemd
builds, resulting in a potentially very dangerous ssh compromise ...
... I would think that
On 4/23/24 11:21, Mary via Bug reports for GNU grep wrote:
Thanks for the suggestion. You're right, this would be better than zgrep
etc.
What happened to the old UNIX concept of
Do one thing.
Do it well.
Then stop.
To grep a compressed stream of bits you just
> Thanks for the suggestion. You're right, this would be better than zgrep
> etc.
>
> I have some qualms though, as the new option would increase the attack
> surface for 'grep', in that you could then execute arbitrary code by
> passing certain options to 'grep'. Is there some safer way to get
One supposes that if the file extension is not trustworthy, one can taste file
like the file command, and use libraries like the gzip libraries to handle
gzipped files as a stream. There are so many others: zip files could be
treated like directories and all the files in them that match the
Thanks for the suggestion. You're right, this would be better than zgrep
etc.
I have some qualms though, as the new option would increase the attack
surface for 'grep', in that you could then execute arbitrary code by
passing certain options to 'grep'. Is there some safer way to get what
you
Hello,
I added an option to grep that filters files through a specified program. The
main purpose for that is to uncompress files using the zcat (or `gzip -d`)
command, or an equivalent for another compression format.
It works like this:
grep -j zcat pattern textfile.gz [textfile2.gz...]
17 matches
Mail list logo
