#
fc12c191 |
| 04-Sep-2024 |
John Baldwin <jhb@FreeBSD.org> |
grep: Default to -p instead of -S.
This matches the documented behavior in the manpage as well as the default behavior on macOS.
PR: 280676 Reported by: Radosław Piliszek <radoslaw.piliszek@gmail.
grep: Default to -p instead of -S.
This matches the documented behavior in the manpage as well as the default behavior on macOS.
PR: 280676 Reported by: Radosław Piliszek <radoslaw.piliszek@gmail.com> Reviewed by: kevans MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D46256
show more ...
|
Revision tags: release/14.1.0, release/13.3.0, release/14.0.0 |
|
#
e738085b |
| 17-Aug-2023 |
Dag-Erling Smørgrav <des@FreeBSD.org> |
Remove my middle name.
|
#
1d386b48 |
| 16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
Remove $FreeBSD$: one-line .c pattern
Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/
|
#
2a63c3be |
| 16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
Remove $FreeBSD$: one-line .c comment pattern
Remove /^/[*/]\s*\$FreeBSD\$.*\n/
|
#
4d846d26 |
| 10-May-2023 |
Warner Losh <imp@FreeBSD.org> |
spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD
The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch up to that fact and revert to their recommended match of
spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD
The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch up to that fact and revert to their recommended match of BSD-2-Clause.
Discussed with: pfg MFC After: 3 days Sponsored by: Netflix
show more ...
|
Revision tags: release/13.2.0 |
|
#
e898a3af |
| 04-Jan-2023 |
Kyle Evans <kevans@FreeBSD.org> |
grep: properly switch EOL indicator with -z
-z is supposed to use only the NUL byte as EOL, but we were inadvertently using both newline and NUL due to REG_NEWLINE in cflags.
The odds of anyone rel
grep: properly switch EOL indicator with -z
-z is supposed to use only the NUL byte as EOL, but we were inadvertently using both newline and NUL due to REG_NEWLINE in cflags.
The odds of anyone relying on this bsdgrep-specific bug are quite low, so let's just fix it. At least one port in the wild has been reported to expect the intended behavior.
Reported by: Hill Ma <maahiuzeon@gmail.com> Triaged by: the self-proclaimed peanut gallery on Discord
show more ...
|
Revision tags: release/12.4.0, release/13.1.0, release/12.3.0 |
|
#
4c14980b |
| 10-Nov-2021 |
Kyle Evans <kevans@FreeBSD.org> |
grep: fix/remove references to -P
-P in gnugrepland means PCRE, which we do not support. We may eventually support it if onigmo ends up getting imported as a more performant regex implementation, a
grep: fix/remove references to -P
-P in gnugrepland means PCRE, which we do not support. We may eventually support it if onigmo ends up getting imported as a more performant regex implementation, and we can re-add it properly in these places (and more) when that time comes.
The optstr change is a functional nop; the case was not explicitly handled, thus ending in usage() anyways.
Reported by: Vladimir Misev (via twitter)
show more ...
|
Revision tags: release/13.0.0 |
|
#
be6b8b7a |
| 05-Feb-2021 |
Mateusz Piotrowski <0mp@FreeBSD.org> |
grep: Fix an incorrect description of the -C flag
It seems that the number of lines is no longer an optional parameter to the -C flag. Document it accordingly both in the manual page and the usage m
grep: Fix an incorrect description of the -C flag
It seems that the number of lines is no longer an optional parameter to the -C flag. Document it accordingly both in the manual page and the usage message.
Reviewed by: yuripv Approved by: yuripv MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D28509
show more ...
|
#
2373acbb |
| 04-Feb-2021 |
Kyle Evans <kevans@FreeBSD.org> |
grep: turn off -w if -x is specified
-x overcomes -w in gnugrep, and it should here as well. Flip it off as needed to avoid confusing other parts of grep.
|
#
f823c6dc |
| 04-Feb-2021 |
Kyle Evans <kevans@FreeBSD.org> |
grep: fix null pattern and empty pattern file behavior
The null pattern semantics were terrible because I tried to match gnugrep, but I got it wrong. Let's unwind that:
- The null pattern should m
grep: fix null pattern and empty pattern file behavior
The null pattern semantics were terrible because I tried to match gnugrep, but I got it wrong. Let's unwind that:
- The null pattern should match every line if neither -w nor -x. - The null pattern should match empty lines if -x. - The null pattern should not match any lines if -w.
The first two will stop processing (shortcut) even if additional patterns are specified. In any other case, we will continue processing other patterns. If no other patterns are specified beside a null pattern, then we match if neither -w nor -x or set and do not match if either of those are specified.
The justification for -w is that it should match on a whole word, but the null pattern deos not have a whole word to match on.
Empty pattern files should never match anything, and more importantly, -v should cause everything to be written.
PR: 253209 MFC-after: 4 days
show more ...
|
#
df546c3b |
| 09-Dec-2020 |
Kyle Evans <kevans@FreeBSD.org> |
grep: replace the internal queue with a ring buffer
We know up front how many items we can have in the queue (-B/Bflag), so pay the cost of those particular allocations early on.
The reduced queue
grep: replace the internal queue with a ring buffer
We know up front how many items we can have in the queue (-B/Bflag), so pay the cost of those particular allocations early on.
The reduced queue maintenance overhead seemed to yield about an ~8% improvement for my earlier `grep -C8 -r closefrom .` test.
MFC after: 2 weeks
show more ...
|
#
7c2f310f |
| 05-Dec-2020 |
Kyle Evans <kevans@FreeBSD.org> |
Retire GNU_GREP_COMPAT knob
This was introduced and then disabled by default primarily to avoid dealing with bugs in libgnuregex. rS363823 switched to using libregex for it, so let's just rip the op
Retire GNU_GREP_COMPAT knob
This was introduced and then disabled by default primarily to avoid dealing with bugs in libgnuregex. rS363823 switched to using libregex for it, so let's just rip the option out now so we can make sure we're getting tested with libregex via bsdgrep.
Reviewed by: emaste Differential Revision: https://reviews.freebsd.org/D27476
show more ...
|
Revision tags: release/12.2.0 |
|
#
440cec3f |
| 12-Aug-2020 |
Glen Barber <gjb@FreeBSD.org> |
MFH
Sponsored by: Rubicon Communications, LLC (netgate.com)
|
#
e383ec74 |
| 06-Aug-2020 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r363739 through r363986.
|
#
cab7d341 |
| 04-Aug-2020 |
Kyle Evans <kevans@FreeBSD.org> |
bsdgrep: switch to libregex for GNU_GREP_COMPAT
libregex is incomplete, but it's a bit less buggy than the in-base libgnuregex and mostly OK.
While here, rename -DIWTH_GNU -> -DWITH_GNU_COMPAT; the
bsdgrep: switch to libregex for GNU_GREP_COMPAT
libregex is incomplete, but it's a bit less buggy than the in-base libgnuregex and mostly OK.
While here, rename -DIWTH_GNU -> -DWITH_GNU_COMPAT; the option implies that we're compatible with the GNU counterpart, not that we're including GNU anything.
show more ...
|
Revision tags: release/11.4.0, release/12.1.0 |
|
#
668ee101 |
| 26-Sep-2019 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r352587 through r352763.
|
#
38325e2a |
| 25-Sep-2019 |
Kyle Evans <kevans@FreeBSD.org> |
bsdgrep(1): various fixes of empty pattern/exit code/-c behavior
When an empty pattern is encountered in the pattern list, I had previously broken bsdgrep to count that as a "match all" and ignore a
bsdgrep(1): various fixes of empty pattern/exit code/-c behavior
When an empty pattern is encountered in the pattern list, I had previously broken bsdgrep to count that as a "match all" and ignore any other patterns in the list. This commit rectifies that mistake, among others:
- The -v flag semantics were not quite right; lines matched should have been counted differently based on whether the -v flag was set or not. procline now definitively returns whether it's matched or not, and interpreting that result has been kicked up a level. - Empty patterns with the -x flag was broken similarly to empty patterns with the -w flag. The former is a whole-line match and should be more strict, only matching blank lines. No -x and no -w will will match the empty string at the beginning of each line. - The exit code with -L was broken, w.r.t. modern grep. Modern grap will exit(0) if any file that didn't match was output, so our interpretation was simply backwards. The new interpretation makes sense to me.
Tests updated and added to try and catch some of this.
This misbehavior was found by autoconf while fixing ports found in PR 229925 expecting either a more sane or a more GNU-like sed.
MFC after: 1 week
show more ...
|
Revision tags: release/11.3.0 |
|
#
0269ae4c |
| 06-Jun-2019 |
Alan Somers <asomers@FreeBSD.org> |
MFHead @348740
Sponsored by: The FreeBSD Foundation
|
#
25385eb3 |
| 02-Jun-2019 |
Kyle Evans <kevans@FreeBSD.org> |
grep: Move lone 'r'grep case into the adjacent switch
This 'r' case should have belonged to the switch in the first place, but I had somehow missed the switch when initially adding the rgrep link. T
grep: Move lone 'r'grep case into the adjacent switch
This 'r' case should have belonged to the switch in the first place, but I had somehow missed the switch when initially adding the rgrep link. The zgrep script later came along and faithfully left this case standing alone, so we will now go ahead and join it.
Nearby comment also adjusted a tad bit for wording and style.
Reported by: Daniel Ebdrup MFC after: 3 days
show more ...
|
Revision tags: release/12.0.0, release/11.2.0 |
|
#
cbfff13f |
| 07-Jun-2018 |
Kyle Evans <kevans@FreeBSD.org> |
bsdgrep(1): Do some less dirty things with return types
Neither procfile nor grep_tree return anything meaningful to their callers. None of the callers actually care about how many lines were matche
bsdgrep(1): Do some less dirty things with return types
Neither procfile nor grep_tree return anything meaningful to their callers. None of the callers actually care about how many lines were matched in all of the files they processed; it's all about "did anything match?"
This is generally just a light refactoring to remind me of what actually matters as I'm rewriting these bits to care less about 'stuff'.
show more ...
|
#
30dc9502 |
| 07-Jun-2018 |
Baptiste Daroussin <bapt@FreeBSD.org> |
Remove NLS support from BSD grep
GNU grep as in actually in base does not have any translations support compiled in, so no functionnality loss.
We do support 193 locales in base, we will never catc
Remove NLS support from BSD grep
GNU grep as in actually in base does not have any translations support compiled in, so no functionnality loss.
We do support 193 locales in base, we will never catch up on that number of translation with bsd grep.
Removing NLS support make bsd grep consistent with the other binaries in base which are not translated, and also reduce a little bit the code.
Reviewed by: kevans Approved by: kevans Discussed with: kevans @BSDCan Differential Revision: https://reviews.freebsd.org/D15682
show more ...
|
#
24a656c2 |
| 08-May-2018 |
Kyle Evans <kevans@FreeBSD.org> |
bsdgrep: Allow "-" to be passed to -f to mean "standard input"
A version of this patch was originally sent to me by se@, matching behavior from newer versions of GNU grep.
While there have been som
bsdgrep: Allow "-" to be passed to -f to mean "standard input"
A version of this patch was originally sent to me by se@, matching behavior from newer versions of GNU grep.
While there have been some differences of opinion on whether stdin should be closed or not after depleting it in process of -f, I've opted to leave stdin open and just let the later matching stuff fail and result in a no-match. I'm not married to the current behavior- it was generally chosen since we are adopting this in particular from GNU grep, and I would like to stay consistent without a strong argument to the contrary. The current behavior isn't technically wrong, it's just fairly unfriendly to the developer-user of grep that may not realize their usage is trivially invalid.
Submitted by: se
show more ...
|
#
a2584d1b |
| 04-May-2018 |
Kyle Evans <kevans@FreeBSD.org> |
bsdgrep: annihilate our in-tree TRE, previously disabled by default
It was an old TRE that had plenty of bugs and no performance gain over regex(3). I disabled it by default in r323615, and there wa
bsdgrep: annihilate our in-tree TRE, previously disabled by default
It was an old TRE that had plenty of bugs and no performance gain over regex(3). I disabled it by default in r323615, and there was some confusion about what the knob does- likely due to poor naming on my part- to the tune of "well, it sounds like it should speed things up" (mentioned by multiple people).
To compound this, I have no intention of maintaining a second regex implementation. If someone would like to step up and volunteer to maintain a lean-and-mean implementation for grep, this is OK, but we have very few volunteers to maintain even our primary regex implementation.
show more ...
|
#
a1852807 |
| 25-Apr-2018 |
Kyle Evans <kevans@FreeBSD.org> |
bsdgrep: Update NLS catalogs after r332995
Compression was removed so #2 goes away and everything else needs renumbered to match, and the usage string was also updated due to removed options.
X-MFC
bsdgrep: Update NLS catalogs after r332995
Compression was removed so #2 goes away and everything else needs renumbered to match, and the usage string was also updated due to removed options.
X-MFC-With: r332995
show more ...
|
#
4a5b4207 |
| 25-Apr-2018 |
Baptiste Daroussin <bapt@FreeBSD.org> |
Remove compression support from bsdgrep
Compression support is now handled by an external script, remove it from the bsdgrep(1) utility. This removes the support for -Z -J -X and -M
Note: that it m
Remove compression support from bsdgrep
Compression support is now handled by an external script, remove it from the bsdgrep(1) utility. This removes the support for -Z -J -X and -M
Note: that it matches the changes in newer GNU grep
Reviewed by: kevans Approved by: kevans MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D15197
show more ...
|