Bug 254110 - grep/bsdgrep(1) -C/--context doesn't behave as advertised
Summary: grep/bsdgrep(1) -C/--context doesn't behave as advertised
Status: Closed Overcome By Events
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Many People
Assignee: Kyle Evans
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-03-07 18:53 UTC by Bob Bishop
Modified: 2021-04-17 20:39 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bob Bishop 2021-03-07 18:53:20 UTC
-C or --context with no count following is supposed to behave as -C2 but instead it is treated as an error. This affects all versions back as far as 7.0-RELEASE.

The 1-character fix is that C: in the option string should be C::, ie two colons not one.
Comment 1 Bob Bishop 2021-03-07 19:00:33 UTC
cf. bug #254091
Comment 2 Kyle Evans freebsd_committer freebsd_triage 2021-03-07 21:34:09 UTC
Let me think on this one; AFAICT the gnugrep that we're replacing never allowed an optional context argument, so that may actually be one POLA violation too far for this point in the release cycle. It's tempting to just fix the documentation and the long option flag to indicate that it's not actually optional.
Comment 3 Bob Bishop 2021-03-07 22:07:01 UTC
(In reply to Kyle Evans from comment #2)
gnugrep reports it as an error and the respective man pages describe the different behaviours accurately so I don't think there's much danger of POLA violation.
Comment 4 Kyle Evans freebsd_committer freebsd_triage 2021-03-07 22:36:06 UTC
(In reply to Bob Bishop from comment #3)

Right, but we've never done what our docs say and neither has anyone else, so we risk breaking grep invocations that rely on GNU or legacy bsdgrep behavior.
Comment 5 Mateusz Piotrowski freebsd_committer freebsd_triage 2021-04-17 20:39:33 UTC
The documentation has been fixed in https://cgit.freebsd.org/src/commit/?id=be6b8b7a3a18acb3b044e144d946392fca05e5d0. I'll close this PR for now as it seems like the documentation issue has been resolved.