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
Dale wrote:
> If these weren't ad-hoc activities, I would construct a careful pipeline
> like
>
> grep -c -r pattern directory | sort -t: -k2,2r | head -n3
>
> but for ad-hoc use, it seems to me that it's sensible and convenient to
> make the combination -c -l do what it intuitively "ought"
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
On 4/25/24 13:10, Dale R. Worley wrote:
One further thing, I haven't written any updates to the manual page or
.texi. Does anyone have suggestions for a good way to do that?
If you have time, just edit those two files and include the edits as
part of your patch. If not, I can write that
Dennis Clarke via Bug reports for GNU grep writes:
> Perhaps a specific example would be helpful.
My most common case is something like
grep -c --files-with-match 'some fragment of a command' ~/temp/shell.10??
which is searching the log files of my old shell sessions to find the
most
Paul Eggert writes:
> On 4/23/24 11:32 AM, Dale R. Worley wrote:
>> However, it seems "natural" to me that "grep -c -l", that is, "grep
>> --count --files-with-matches", should give me this result.
>
> Yes, that sounds reasonable. Is your patch a trivial one (10 lines or
> less)? If so, please
