Dave Voutila <[email protected]> wrote:
> I noticed this today while grepping through a very long kdump output and
> using something like:
>
> $ fgrep -n -m2 -C2 'kevent -1' dump.txt
> 641- 31513 vmd RET sendmsg 1848/0x738
> 642- 31513 vmd CALL kevent(5,0x90d4c2e4000,1,0x90d8004a000,2048,0)
> 643: 31513 vmd RET kevent -1 errno 4 Interrupted system call
> 644- 31513 vmd CALL sigreturn(0x7f7ffffd6430)
> 645- 31513 vmd RET sigreturn JUSTRETURN
> --
> 661- 31513 vmd RET sendmsg 44/0x2c
> 662- 31513 vmd CALL kevent(5,0x90d4c2e4000,1,0x90d8004a000,2048,0)
> 663: 31513 vmd RET kevent -1 errno 4 Interrupted system call
>
> Notice how grep(1) isn't printing anything after the last requested
> match even though I've specified -C2. (I assure you...there're a lot
> more lines after that match. ;)
>
> The below patch changes the logic to avoid bailing out of the loop in
> util.c:procfile() even after the match count is hit but we still have
> some after-context lines to print.
>
> In procline(), it will skip attempting matches after hitting the match
> count. (This does mean that when using -n, a line within the
> after-context that may match will not get printed with the matched
> prefix ":".)
>
> With the diff:
>
> $ fgrep -n -m2 -C2 'kevent -1' dump.txt
> 641- 31513 vmd RET sendmsg 1848/0x738
> 642- 31513 vmd CALL kevent(5,0x90d4c2e4000,1,0x90d8004a000,2048,0)
> 643: 31513 vmd RET kevent -1 errno 4 Interrupted system call
> 644- 31513 vmd CALL sigreturn(0x7f7ffffd6430)
> 645- 31513 vmd RET sigreturn JUSTRETURN
> --
> 661- 31513 vmd RET sendmsg 44/0x2c
> 662- 31513 vmd CALL kevent(5,0x90d4c2e4000,1,0x90d8004a000,2048,0)
> 663: 31513 vmd RET kevent -1 errno 4 Interrupted system call
> 664- 31513 vmd CALL sigreturn(0x7f7ffffd6430)
> 665- 31513 vmd RET sigreturn JUSTRETURN
>
> FWIW: GNU grep (v3.3) seems to do my proposed behavior including not
> marking possible matches in the after-context of a final match. Busybox
> grep (v1.33.1) acts like our current grep and fails to print the
> after-context of the final match when using -m.
>
> ok?
the current behaviour seems a bug to me more than a feature: i think we
should honour -C even when -m is specified.
not my department, but recently i was hacking in grep too and the diff
reads and works fine to me. ok op@ (given my ok counts something in
this area :-)
> @@ -212,6 +212,8 @@ procline(str_t *l, int nottext)
> c = 1;
> goto print;
> }
nitpick: i'd probably add a space between <= and 0
> + if (mflag && mcount <=0)
> + goto print;
>
> for (i = 0; i < patterns; i++) {
> offset = 0;
