aboutsummaryrefslogtreecommitdiff
path: root/usr.bin/grep/util.c
Commit message (Collapse)AuthorAgeFilesLines
* grep: fix combination of quite and count flagMariusz Zaborski2021-07-091-1/+1
| | | | | | | | | | | | | | | | | When the quite (-q) flag is provided, we don't expect any output. Currently, the behavior is broken: $ grep -cq flag util.c 1 $ grep -cs flag util.c 55 First of all, we print a number to stdout. Secondly, it just returns 0 or 1 (which is unexpected). GNU grep with c and q flags doesn't print anything. Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D31108
* grep: fix -A handling in conjunction with -m match limitationKyle Evans2021-02-081-1/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 MFC-after: 3 days
* grep: fix null pattern and empty pattern file behaviorKyle Evans2021-02-051-19/+16
| | | | | | | | | | | | | | | | | | | | | | | | 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
* fts_read: Handle error from a NULL return better.Bryan Drewery2020-12-081-1/+3
| | | | | | | | | | | | | | | | | | | | This is addressing cases such as fts_read(3) encountering an [EIO] from fchdir(2) when FTS_NOCHDIR is not set. That would otherwise be seen as a successful traversal in some of these cases while silently discarding expected work. As noted in r264201, fts_read() does not set errno to 0 on a successful EOF so it needs to be set before calling it. Otherwise we might see a random error from one of the iterations. gzip is ignoring most errors and could be improved separately. Reviewed by: vangyzen Sponsored by: Dell EMC Differential Revision: https://reviews.freebsd.org/D27184 Notes: svn path=/head/; revision=368467
* bsdgrep(1): various fixes of empty pattern/exit code/-c behaviorKyle Evans2019-09-251-12/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 Notes: svn path=/head/; revision=352691
* bsdgrep(1): Remove redundant initialization; unconditionally assigned laterKyle Evans2018-06-151-1/+0
| | | | Notes: svn path=/head/; revision=335188
* bsdgrep(1): Some more int -> bool conversions and name changesKyle Evans2018-06-091-20/+25
| | | | | | | | | Again motivated by upcoming work to rewrite a bunch of this- single-letter variable names and slightly misleading variable names ("lastmatches" to indicate that the last matched) are not helpful. Notes: svn path=/head/; revision=334889
* bsdgrep(1): Slooowly peel away the chunky onionKyle Evans2018-06-081-16/+5
| | | | | | | | | | | | | | | | | | | | (or peel off the band-aid, whatever floats your boat) This addresses two separate issues: 1.) Nothing within bsdgrep actually knew whether it cared about line numbers or not. 2.) The file layer knew nothing about the context in which it was being called. #1 is only important when we're *not* processing line-by-line. #2 is debatably a good idea; the parsing context is only handy because that's where we store current offset information and, as of this commit, whether or not it needs to be line-aware. Notes: svn path=/head/; revision=334821
* bsdgrep(1): Don't initialize fts_flags twiceKyle Evans2018-06-071-1/+1
| | | | | | | | | Admittedly, this is a clang-scan complaint... but it wasn't wrong. fts_flags is initialized by all cases in the switch(), which should be fairly obvious. Annotate this anyways. Notes: svn path=/head/; revision=334808
* bsdgrep(1): whoops, garbage collect the now write-only variableKyle Evans2018-06-071-2/+2
| | | | Notes: svn path=/head/; revision=334807
* bsdgrep(1): Do some less dirty things with return typesKyle Evans2018-06-071-17/+18
| | | | | | | | | | | | 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'. Notes: svn path=/head/; revision=334806
* Remove NLS support from BSD grepBaptiste Daroussin2018-06-061-2/+2
| | | | | | | | | | | | | | | | | | | 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 Notes: svn path=/head/; revision=334744
* bsdgrep: annihilate our in-tree TRE, previously disabled by defaultKyle Evans2018-05-041-15/+2
| | | | | | | | | | | | | | | | 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. Notes: svn path=/head/; revision=333236
* bsdgrep: Adjust a missed NLS reference that was invalidated by recent workKyle Evans2018-05-021-1/+1
| | | | | | | Submitted by: Dan McGregor <dan.mcgregor@usask.ca> Notes: svn path=/head/; revision=333172
* bsdgrep: Use grep_strdup instead of grep_malloc+strcpyKyle Evans2018-04-211-2/+1
| | | | Notes: svn path=/head/; revision=332858
* bsdgrep: Fix --include/--exclude ordering issuesKyle Evans2018-04-211-4/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Prior to r332851: * --exclude always win out over --include * --exclude-dir always wins out over --include-dir r332851 broke that behavior, resulting in: * First of --exclude, --include wins * First of --exclude-dir, --include-dir wins As it turns out, both behaviors are wrong by modern grep standards- the latest rule wins. e.g.: `grep --exclude foo --include foo 'thing' foo` foo is included `grep --include foo --exclude foo 'thing' foo` foo is excluded As tested with GNU grep 3.1. This commit makes bsdgrep follow this behavior. Reported by: se Notes: svn path=/head/; revision=332856
* bsdgrep: More trivial cleanup/style cleanupKyle Evans2018-04-211-14/+5
| | | | | | | We can avoid branching for these easily reduced patterns Notes: svn path=/head/; revision=332851
* bsdgrep: Some light cleanupKyle Evans2018-04-211-5/+5
| | | | | | | | | | | There's no point checking for a bunch of file modes if we're not a practicing believer of DIR_SKIP or DEV_SKIP. This also reduces some style violations that were particularly ugly looking when browsing through. Notes: svn path=/head/; revision=332850
* bsdgrep: Break procmatches down a little bit moreKyle Evans2018-04-201-43/+54
| | | | | | | | | Split the matching and non-matching cases out into their own functions to reduce future complexity. As the name implies, procmatches will eventually process more than one match itself in the future. Notes: svn path=/head/; revision=332832
* bsdgrep: Add some TODOs for future work on operating on chunksKyle Evans2018-04-201-0/+12
| | | | Notes: svn path=/head/; revision=332809
* bsdgrep: Clean up procmatches a little bitKyle Evans2018-04-201-31/+32
| | | | Notes: svn path=/head/; revision=332806
* bsdgrep: Split match processing out of procfileKyle Evans2018-04-201-65/+87
| | | | | | | | procfile is getting kind of hairy, and it's not going to get better as we correct some more bits that assume we process one line at a time. Notes: svn path=/head/; revision=332805
* various: general adoption of SPDX licensing ID tags.Pedro F. Giffuni2017-11-271-0/+2
| | | | | | | | | | | | | | | | | Mainly focus on files that use BSD 2-Clause license, however the tool I was using misidentified many licenses so this was mostly a manual - error prone - task. The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts. No functional change intended. Notes: svn path=/head/; revision=326276
* bsdgrep: add a primitive literal matcherKyle Evans2017-08-241-1/+70
| | | | | | | | | | | | | | | | | | | | | | | | | fgrep/grep -F will error out at runtime if compiled with a regex(3) that does not define REG_NOSPEC or REG_LITERAL. glibc is one such regex(3) implementation, and as it turns out they don't support literal matching at all. Provide a primitive literal matcher for use with glibc and other implementations that don't support literal matching so that we don't completely lose fgrep/grep -F if compiled against libgnuregex on stable/10, stable/11, or other systems that we don't necessarily support. This is a wholly unoptimized implementation with no plans to optimize it as of now. This is due to both its use-case being primarily on unsupported systems in the near-distant future and that it's reinventing the wheel that we already have available as a feature of regex(3). Reviewed by: cem, emaste, ngie Approved by: emaste (mentor) MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D12056 Notes: svn path=/head/; revision=322826
* bsdgrep: cast pmatch.rm_so to fix build when linking against libgnuregexKyle Evans2017-08-171-1/+1
| | | | | | | | | Reported by: many Approved by: emaste (mentor) MFC after: immediate Notes: svn path=/head/; revision=322618
* bsdgrep(1): Don't exit before processing every fileKyle Evans2017-07-251-10/+2
| | | | | | | | | | | | | | | Given an empty pattern (i.e. grep "" A B), bsdgrep(1) would previously exit() with the appropriate exit code upon encountering an empty file. Likely intended as an optimization, but this behavior is technically incorrect since an empty pattern should match every line. PR: 220924 Reviewed by: emaste, cem (earlier version), ngie Approved by: emaste (mentor) Differential Revision: https://reviews.freebsd.org/D11698 Notes: svn path=/head/; revision=321450
* Update copyright e-mail address to @FreeBSD.org addressKyle Evans2017-07-061-1/+1
| | | | | | | | Approved by: emaste (mentor) Differential Revision: https://reviews.freebsd.org/D11508 Notes: svn path=/head/; revision=320754
* bsdgrep: bump version number and add Kyle Evans copyrightEd Maste2017-05-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The following changes have been made over the last couple of months: Features: - With bsdgrep -r, the working directory is implied if no directory is specified - bsdgrep will now behave as bsdgrep -r does when it's named rgrep - bsdgrep now understands -z/--null-data to use \0 as EOL - GNU regex compatibility is now indicated with a "GNU compatible" in the version string Fixes: - --mmap no longer hangs when coming across an EOF without an accompanying EOL - -o/--color matching generally improved, now produces earliest / longest matches - Context output now more closely aligns with GNU grep - Zero-length matches no longer exhibit broken behavior - Every output line now honors -b/-H/-n flags Tests have been added for previous regressions as well as other previously untested behaviors. Various other fixes have been commited, and refactoring for further / later improvements has taken place. (The original submission changed the version string to 2.5.2, but I decided to use 2.6.0 to reflect the addition of new features.) Submitted by: Kyle Evans <kevans91@ksu.edu> Differential Revision: https://reviews.freebsd.org/D10982 Notes: svn path=/head/; revision=319132
* bsdgrep: correct assumptions to prepare for chunkingEd Maste2017-05-261-4/+4
| | | | | | | | | | | | Correct a couple of minor BSD grep assumptions that are valid for line processing but not future chunk-based processing. Submitted by: Kyle Evans <kevans91@ksu.edu> Reviewed by: bapt, cem Differential Revision: https://reviews.freebsd.org/D10824 Notes: svn path=/head/; revision=318914
* bsdgrep: Correct per-line line metadata printingEd Maste2017-05-201-10/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Metadata printing with -b, -H, or -n flags suffered from a few flaws: 1) -b/offset printing was broken when used in conjunction with -o 2) With -o, bsdgrep did not print metadata for every match/line, just the first match of a line 3) There were no tests for this Address these issues by outputting this data per-match if the -o flag is specified, and prior to outputting any matches if -o but not --color, since --color alone will not generate a new line of output for every iteration over the matches. To correct -b output, fudge the line offset as we're printing matches. While here, make sure we're using grep_printline in -A context. Context printing should *never* look at the parsing context, just the line. The tests included do not pass with gnugrep in base due to it exhibiting similar quirky behavior that bsdgrep previously exhibited. Submitted by: Kyle Evans <kevans91@ksu.edu> Reviewed by: cem Differential Revision: https://reviews.freebsd.org/D10580 Notes: svn path=/head/; revision=318574
* bsdgrep: emit more than MAX_LINE_MATCHES per lineEd Maste2017-05-201-7/+23
| | | | | | | | | | | | | | | | | | | | | | | | We should not set an arbitrary cap on the number of matches on a line, and in any case MAX_LINE_MATCHES of 32 is much too low. Instead, if we match more than MAX_LINE_MATCHES, keep processing and matching from the last match until all are found. For the regression test, we produce 4096 matches (larger than we expect we'll ever set MAX_LINE_MATCHES) and make sure we actually get 4096 lines of output with the -o flag. We'll also make sure that every distinct line is getting its own line number to detect line metadata not being printed as appropriate along the way. PR: 218811 Submitted by: Kyle Evans <kevans91@ksu.edu> Reported by: jbeich Reviewed by: cem Differential Revision: https://reviews.freebsd.org/D10577 Notes: svn path=/head/; revision=318571
* bsdgrep: don't allow negative -A / -B / -CEd Maste2017-05-151-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Previously, when given a negative -A/-B/-C argument bsdgrep would overflow the respective context flag(s) and exhibited surprising behavior. Fix this by removing unsignedness of Aflag/Bflag and erroring out if we're given a value < 0. Also adjust the type used to track 'tail' context in procfile() so that it accurately reflects the Aflag value rather than overflowing and losing trailing context. This also fixes an inconsistency previously existing between -n and -C "n" behavior. They are now both limited to LLONG_MAX, to be consistent. Add some test cases to make sure grep errors out properly for both negative context values as well as non-numeric context values rather than giving bogus matches. Submitted by: Kyle Evans <kevans91@ksu.edu> Reviewed by: cem Differential Revision: https://reviews.freebsd.org/D10675 Notes: svn path=/head/; revision=318302
* bsdgrep: don't ouptut matches with -c, -l, -LEd Maste2017-05-051-5/+7
| | | | | | | | | | | | | | | | | | | | Refactoring done in r317703 broke -c, -l, and -L flags implying suppression of match printing. Fortunately this is just a matter of not doing any printing of the resulting matches and context printing was not broken in this refactoring. Add some regression tests since this area may still see further refactoring, include different context flags as well even though they were not broken in this case. PR: 219077 Submitted by: Kyle kevans91@ksu.edu Reported by: markj Reviewed by: cem, ngie Differential Revision: https://reviews.freebsd.org/D10607 Notes: svn path=/head/; revision=317842
* bsdgrep: correct uninitialized variable introduced in r317703Ed Maste2017-05-031-6/+6
| | | | | | | | CID: 1374747 Submitted by: Kyle Evans <kevans91@ksu.edu> Notes: svn path=/head/; revision=317741
* bsdgrep: fix -w flag matching with an empty patternEd Maste2017-05-021-159/+214
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -w flag matching with an empty pattern was generally 'broken', allowing matches to occur on any line whether or not it actually matches -w criteria. This fix required a good amount of refactoring to address. procline() is altered to *only* process the line and return whether it was a match or not, necessary to be able to short-circuit the whole function in case of this matchall flag. -m flag handling is moved out as well because it suffers from the same fate as context handling if we bypass any actual pattern matching. The matching context (matches, mostly) didn't previously exist outside of procline(), so we go ahead and create context object for file processing bits to pass around. grep_printline() was created due to this, for the scenarios where the matches don't actually matter and we just want to print a line or two, a la flushing the context queue and no -o or --color specified. Damage from this broken behavior would have been mitigated by the fact that it is unlikely users would invoke grep -w with an empty pattern. This was identified while checking PR 105221 for problems it this may cause in BSD grep, but PR 105221 is *not* a report of this behavior. Submitted by: Kyle Evans <kevans91 at ksu.edu> Differential Revision: https://reviews.freebsd.org/D10433 Notes: svn path=/head/; revision=317703
* bsdgrep: fix -w -v matching improperly with certain patternsEd Maste2017-05-021-3/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -w and -v flag matching was mostly functional but had some minor problems: 1. -w flag processing only allowed one iteration through pattern matching on a line. This was problematic if one pattern could match more than once, or if there were multiple patterns and the earliest/ longest match was not the most ideal, and 2. Previous work "fixed" things to not further process a line if the first iteration through patterns produced no matches. This is clearly wrong if we're dealing with the more restrictive -w matching. #2 breakage could have also occurred before recent broad rewrites, but it would be more arbitrary based on input patterns as to whether or not it actually affected things. Fix both of these by forcing a retry of the patterns after advancing just past the start of the first match if we're doing more restrictive -w matching and we didn't get any hits to start with. Also move -v flag processing outside of the loop so that we have a greater change to match in the more restrictive cases. This wasn't strictly wrong, but it could be a little more error prone. While here, introduce some regressions tests for this behavior and fix some excessive wrapping nearby that hindered readability. GNU grep passes these new tests. PR: 218467, 218811 Submitted by: Kyle Evans <kevans91 at ksu.edu> Reviewed by: cem, ngie Differential Revision: https://reviews.freebsd.org/D10329 Notes: svn path=/head/; revision=317665
* bsdgrep: add BSD_GREP_FASTMATCH knob for built-in fastmatchEd Maste2017-04-211-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Bugs have been found in the fastmatch implementation as used in bsdgrep. Some have been fixed (r316495) while fixes for others are in review (D10098). In comparison with the fastmatch implementation, Kyle Evans found that: - regex(3)'s performance with literal expressions offers a speed improvement over fastmatch - regex(3)'s performance, both with simple BREs and EREs, seems to be comparable The regex implementation was imported in r226035, and the commit message reports: This is a temporary solution until the whole regex library is not replaced so that BSD grep development can continue and the backported code gets some review and testing. This change only improves scalability slightly, there is no big performance boost yet but several minor bugs have been found and fixed. Introduce a WITH_/WITHOUT_BSD_GREP_FASTMATCH knob to support testing of both approaches. PR: 175314, 194823 Submitted by: Kyle Evans <kevans91 at ksu.edu> Reviewed by: bdrewery (in part) Differential Revision: https://reviews.freebsd.org/D10282 Notes: svn path=/head/; revision=317254
* bsdgrep: fix zero-length matches without the -o flagEd Maste2017-04-171-3/+3
| | | | | | | | | | | | | | r316477 broke zero-length matches when not using the -o flag, by skipping over them entirely. Add a regression test so that it doesn't break again in the future. Submitted by: Kyle Evans <kevans91 at ksu.edu> Reviewed by: cem emaste ngie Differential Revision: https://reviews.freebsd.org/D10333 Notes: svn path=/head/; revision=317052
* bsdgrep: remove output separators between overlapping segmentsEd Maste2017-04-171-6/+27
| | | | | | | | | | | | | | | | | | Make bsdgrep more sensitive to context overlaps. If it's printing context that either overlaps or is immediately adjacent to another bit of context, don't print a separator. - Non-overlapping segments no longer have two separators between them - Overlapping segments no longer have separators between them with overlapping sections repeated Submitted by: Kyle Evans <kevans91 at ksu.edu> Reviewed by: cem Differential Revision: https://reviews.freebsd.org/D10105 Notes: svn path=/head/; revision=317051
* bsdgrep: for -r, use the working directory if none specifiedEd Maste2017-04-171-1/+4
| | | | | | | | | | | | | | This is more sensible than the previous behaviour of grepping stdin, and matches newer GNU grep behaviour. PR: 216307 Submitted by: Kyle Evans <kevans91 at ksu.edu> Reviewed by: cem, emaste, ngie Relnotes: Yes Differential Revision: https://reviews.freebsd.org/ Notes: svn path=/head/; revision=317050
* bsdgrep: add -z/--null-data supportEd Maste2017-04-171-2/+2
| | | | | | | | | | | | | | -z treats input and output data as sequences of lines terminated by a zero byte instead of a newline. This brings it more in line with GNU grep and brings us closer to passing the current tests with BSD grep. Submitted by: Kyle Evans <kevans91 at ksu.edu> Reviewed by: cem Relnotes: Yes Differential Revision: https://reviews.freebsd.org/D10101 Notes: svn path=/head/; revision=317049
* bsdgrep: revert color changes from r316477Ed Maste2017-04-041-2/+2
| | | | | | | | | | | | | r316477 changed the color output to match exactly the in-tree GNU grep, but introduces unnecessary escape sequences. Submitted by: Kyle Evans <kevans91 at ksu.edu> Reported by: ache MFC after: 1 month MFC with: r316477 Notes: svn path=/head/; revision=316491
* bsdgrep: Initialize vars to avoid a false positive GCC warningEd Maste2017-04-041-0/+3
| | | | | | | | | Reported by: lwhsu MFC after: 1 month MFC with: r316477 Notes: svn path=/head/; revision=316489
* bsdgrep: fix matching behaviourEd Maste2017-04-031-17/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - 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 Notes: svn path=/head/; revision=316477
* Call basename() in a portable way.Ed Schouten2016-07-281-5/+10
| | | | | | | | | Pull a copy of the filename string before calling basename(). Change the loop to not return on its own, so we can put a free() statement at the bottom. Notes: svn path=/head/; revision=303444
* - Do not look for more matching lines if -L is specifiedGabor Kovesdan2014-08-181-1/+1
| | | | | | | | Submitted by: eadler (based on) MFC after: 2 weeks Notes: svn path=/head/; revision=270132
* grep: Fix type.Pedro F. Giffuni2014-07-171-1/+1
| | | | | | | | Obtained from: NetBSD (CVS rev. 1.17) MFC after: 3 days Notes: svn path=/head/; revision=268798
* Fix a bug in bsdgrep(1) where patterns are not correctlyGlen Barber2014-06-201-1/+1
| | | | | | | | | | | | | | | | | | detected. Certain criteria must be met for this bug to show up: * the -w flag is specified, and * neither -o or --color are specified, and * the pattern is part of another word in the line, and * the other word that contains the pattern occurs first PR: 181973 MFC after: 3 days Sponsored by: The FreeBSD Foundation Notes: svn path=/head/; revision=267693
* Make bsdgrep behave as gnugrep and as documented: -m should only stopEitan Adler2012-12-201-2/+1
| | | | | | | | | | | | reading the specific file, not any file. Tested by: frogs (irc) Reviewed by: gabor Approved by: cperciva (implicit) MFC after: 1 week Notes: svn path=/head/; revision=244493
* - Match GNU behavior of exit codeGabor Kovesdan2011-12-071-3/+2
| | | | | | | | | | | - Rename variable that has a different meaning now PR: bin/162930 Submitted by: Jan Beich <jbeich@tormail.net> MFC after: 1 week Notes: svn path=/head/; revision=228319
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-01 08:33:13 +0000