History log of /freebsd/usr.bin/grep/grep.c (Results 1 – 25 of 96)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 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 ...


1234