Create a convenience rgrep link for bsdgrep(1) that observes 'grep -r'
behavior.
A follow-up to r316473.
Submitted by: Kyle Evans <kevans91 at ksu.edu>
Reviewed by: emaste (earlier version), cem
Differential Revision: https://reviews.freebsd.org/D10109
- 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
MSDOS and Windows GNU grep uses -u to mean "print byte offsets as if
running on an UNIX system." The option has no effect on systems that
do not use CRLF line endings.
PR: 171200
Submitted by: deeptech71@gmail.com, Anders Jensen-Waud
MFC after: 1 month
Rework part of the loop in grep_fgetln to return the rest of the line
and ensure that we still advance the buffer by the length of the rest
of the line.
PR: 165471
Submitted by: Kyle Evans <kevans91@ksu.edu>
MFC after: 1 month
or "+" (these are invalid, because there is no preceding operand).
When bsdgrep attempts to emulate GNU grep in discarding and ignoring the
invalid ? or + operators, some later logic in tre_compile_fast() goes
beyond the end of the buffer, leading to a crash.
Fix this by bailing out, and reporting a bad pattern instead.
Reported by: Steve Kargl
MFC after: 1 week
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.
after r298107
Summary of changes:
- Replace all instances of FILES/TESTS with ${PACKAGE}FILES. This ensures that
namespacing is kept with FILES appropriately, and that this shouldn't need
to be repeated if the namespace changes -- only the definition of PACKAGE
needs to be changed
- Allow PACKAGE to be overridden by callers instead of forcing it to always be
`tests`. In the event we get to the point where things can be split up
enough in the base system, it would make more sense to group the tests
with the blocks they're a part of, e.g. byacc with byacc-tests, etc
- Remove PACKAGE definitions where possible, i.e. where FILES wasn't used
previously.
- Remove unnecessary TESTSPACKAGE definitions; this has been elided into
bsd.tests.mk
- Remove unnecessary BINDIRs used previously with ${PACKAGE}FILES;
${PACKAGE}FILESDIR is now automatically defined in bsd.test.mk.
- Fix installation of files under data/ subdirectories in lib/libc/tests/hash
and lib/libc/tests/net/getaddrinfo
- Remove unnecessary .include <bsd.own.mk>s (some opportunistic cleanup)
Document the proposed changes in share/examples/tests/tests/... via examples
so it's clear that ${PACKAGES}FILES is the suggested way forward in terms of
replacing FILES. share/mk/bsd.README didn't seem like the appropriate method
of communicating that info.
MFC after: never probably
X-MFC with: r298107
PR: 209114
Relnotes: yes
Tested with: buildworld, installworld, checkworld; buildworld, packageworld
Sponsored by: EMC / Isilon Storage Division
some combinations of command line options and search patterns. The code was
examining regexec flags looking for a regcomp flag value. The fix is to
look in the struct field where the decoded regcomp flag was stored when the
regex was compiled.
With this fix, it's possible to build WITHOUT_GNU_GREP_COMPAT and
WITH_BSDGREP and have a usable GPL-free grep (which of course lacks gnugrep
extensions). It now passes the kyua tests except for one test that requires
the -z/--null-data gnu extension, and one test involving outputting context
lines across multiple files which appears to sometimes output an extra
delimiter line ("--") between matches (a rather obscure failure of a rather
obscure feature, so bsdgrep should be generally usable now).
netbsd-tests.test.mk (r289151)
- Eliminate explicit OBJTOP/SRCTOP setting
- Convert all ad hoc NetBSD test integration over to netbsd-tests.test.mk
- Remove unnecessary TESTSDIR setting
- Use SRCTOP where possible for clarity
MFC after: 2 weeks
Sponsored by: EMC / Isilon Storage Divison
This is required by our FORTIFY_SOURCE implementation as it
does more inlining. As a rule of thumb, FORTIFY_SOURCE doubles
the number of inlines except that in grep inlining
blows up for some reason.
Off by default, build behaves normally.
WITH_META_MODE we get auto objdir creation, the ability to
start build from anywhere in the tree.
Still need to add real targets under targets/ to build packages.
Differential Revision: D2796
Reviewed by: brooks imp
Some users build FreeBSD as non-root in Perforce workspaces. By default,
Perforce sets files read-only unless they're explicitly being edited.
As a result, the -f argument must be used to cp in order to override the
read-only flag when copying source files to object directories. Bare use of
'cp' should be avoided in the future.
Update all current users of 'cp' in the src tree.
Reviewed by: emaste
MFC after: 1 week
Sponsored by: Spectra Logic
Makefiles should not assume that source files can be overwritten. This is the
common case for Perforce source trees.
This is a followup commit to r211243 in the same vein.
MFC after: 1 month
Sponsored by: Spectra Logic
MFSpectraBSD: r1036319 on 2014/01/29, r1046711 on 2014/03/06
Bring a couple of changes from NetBSD:
queue.c (CVS Rev. 1.4. 1.5)
Fix memory leaks.
NULL does not need a cast.
grep.c (CVS Rev. 1.6)
Use the more portable getline.
Obtained from: NetBSD
MFC after: 3 days
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
