Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 11 Feb 2021 15:21:55 +0000
From:      bugzilla-noreply@freebsd.org
To:        bugs@FreeBSD.org
Subject:   [Bug 253350] Grep regression with --after-context (-A) and --max-count (-m) switches
Message-ID:  <bug-253350-227-BbU4TMG8KV@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-253350-227@https.bugs.freebsd.org/bugzilla/>
References:  <bug-253350-227@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253350

--- Comment #5 from commit-hook@FreeBSD.org ---
A commit in branch stable/12 references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=3Dad488c9793fd5040f8267620f370f319d=
f31af2d

commit ad488c9793fd5040f8267620f370f319df31af2d
Author:     Kyle Evans <kevans@FreeBSD.org>
AuthorDate: 2021-02-08 18:31:17 +0000
Commit:     Kyle Evans <kevans@FreeBSD.org>
CommitDate: 2021-02-11 15:20:26 +0000

    grep: fix -A handling in conjunction with -m match limitation

    The basic issue here is that grep, when given -m 1, would stop all
    line processing once it hit the match count and exit immediately.  The
    problem with exiting immediately is that -A processing only happens when
    subsequent lines are processed and do not match.

    The fix here is relatively easy; when bsdgrep matches a line, it resets
    the 'tail' of the matching context to the value supplied to -A and
    dumps anything that's been queued up for -B. After the current line has
    been printed and tail is reset, we check our mcount and do what's
    needed. Therefore, at the time that we decide we're doing nothing, we
    know that 'tail' of the context is correct and we can simply continue
    on if there's still more to pick up.

    With this change, we still bail out immediately if there's been no -A
    flag. If -A was supplied, we signal that we should continue on. However,
    subsequent lines will not even bothere to try and process the line.  We
    have reached the match count, so even if the next line would match then
    we must process it if it hadn't. Thus, the loop in procfile() can
    short-circuit and just process the line as a non-match until
    procmatches() indicates that it's safe to stop.

    A test has been added to reflect both that we should be picking up the
    next line and that the next line should be considered a non-match even
    if it should have been.

    PR:             253350

    (cherry picked from commit 3e2d96ac974db823255a6f40b90eeffa6e38d022)

 contrib/netbsd-tests/usr.bin/grep/t_grep.sh | 17 +++++++++++++++++
 usr.bin/grep/util.c                         | 21 ++++++++++++++++++++-
 2 files changed, 37 insertions(+), 1 deletion(-)

--=20
You are receiving this mail because:
You are on the CC list for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-253350-227-BbU4TMG8KV>