Date: Mon, 03 Apr 2017 23:17:37 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 209116] bsdgrep -Fxf failing if earlier non-match is a sub-prefix of the actual match Message-ID: <bug-209116-8-fqLykHpfnM@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-209116-8@https.bugs.freebsd.org/bugzilla/> References: <bug-209116-8@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=3D209116 --- Comment #2 from commit-hook@freebsd.org --- A commit references this bug: Author: emaste Date: Mon Apr 3 23:16:52 UTC 2017 New revision: 316477 URL: https://svnweb.freebsd.org/changeset/base/316477 Log: bsdgrep: fix matching behaviour - Set REG_NOTBOL if we've already matched beginning of line and we're examining later parts - For each pattern we examine, apply it to the remaining bits of the line rather than (potentially) smaller subsets - Check for REG_NOSUB after we've looked at all patterns initially matching the line - Keep track of the last match we made to later determine if we're simply not matching any longer or if we need to proceed another byte because we hit a zero-length match - Match the earliest and longest bit of each line before moving the beginning of what we match to further in the line, past the end of the longest match; this generally matches how gnugrep(1) seems to behave, and seems like pretty good behavior to me - Finally, bail out of printing any matches if we were set to print all (empty pattern) but -o (output matches) was set PR: 195763, 180990, 197555, 197531, 181263, 209116 Submitted by: "Kyle Evans" <kevans91@ksu.edu> Reviewed by: cem MFC after: 1 month Relnotes: Yes Differential Revision: https://reviews.freebsd.org/D10104 Changes: head/usr.bin/grep/util.c --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-209116-8-fqLykHpfnM>