- restore texinfo macros for SLE15
also match e.g., the Arabic digits: ٠١٢٣٤٥٦٧٨٩.
- GNU grep 3.8 (jsc#PED-6579):
* The -s option no longer suppresses "binary file matches"
- use release keyring rather than full one for validation
- Make profiling deterministic (bsc#1040589, SLE-24115)
* --files-without-match (-L) behavior reverted to again succeed
* When standard output is /dev/null, grep no longer fails when
- Drop upstreamed proc-lseek-glitch.patch
an invalid regular expression that was read from an
* grep -z would match strings it should not. To trigger the bug,
you'd have to use a regular expression including an anchor
(^ or $) and a feature like a range or a backreference, causing
With a multibyte locale, that matcher could mistakenly match a
string containing a newline. For example, this command:
would mistakenly match and print all four input bytes. After
* grep -Pz now diagnoses attempts to use patterns containing ^
and $, instead of mishandling these patterns. This problem
seems to be inherent to the PCRE API; removing this limitation
is on PCRE's maint/README wish list. Patterns can continue to
match literal ^ and $ by escaping them with \ (now needed even
* Binary files are now less likely to generate diagnostics and
more likely to yield text matches. grep now reports "Binary
file FOO matches" and suppresses further output instead of
outputting a line containing an encoding error; hence grep can
now report matching text before a later binary match.
Formerly, grep reported FOO to be binary when it found an
encoding error in FOO before generating output for FOO, which
meant it never reported both matching text and matching binary
OBS-URL: https://build.opensuse.org/request/show/1166714
OBS-URL: https://build.opensuse.org/package/show/openSUSE:Factory/grep?expand=0&rev=91
* The -s option no longer suppresses "binary file matches"
- use release keyring rather than full one for validation
- Make profiling deterministic (bsc#1040589, SLE-24115)
* --files-without-match (-L) behavior reverted to again succeed
* When standard output is /dev/null, grep no longer fails when
- Drop upstreamed proc-lseek-glitch.patch
an invalid regular expression that was read from an
* grep -z would match strings it should not. To trigger the bug,
you'd have to use a regular expression including an anchor
(^ or $) and a feature like a range or a backreference, causing
With a multibyte locale, that matcher could mistakenly match a
string containing a newline. For example, this command:
would mistakenly match and print all four input bytes. After
* grep -Pz now diagnoses attempts to use patterns containing ^
and $, instead of mishandling these patterns. This problem
seems to be inherent to the PCRE API; removing this limitation
is on PCRE's maint/README wish list. Patterns can continue to
match literal ^ and $ by escaping them with \ (now needed even
* Binary files are now less likely to generate diagnostics and
more likely to yield text matches. grep now reports "Binary
file FOO matches" and suppresses further output instead of
outputting a line containing an encoding error; hence grep can
now report matching text before a later binary match.
Formerly, grep reported FOO to be binary when it found an
encoding error in FOO before generating output for FOO, which
meant it never reported both matching text and matching binary
data; this was less useful for searching text containing
encoding errors in non-matching lines. [bug introduced in
* grep -c no longer stops counting when finding binary data.
OBS-URL: https://build.opensuse.org/package/show/Base:System/grep?expand=0&rev=142
to be able to identify remaining usages
also match e.g., the Arabic digits: ٠١٢٣٤٥٦٧٨٩.
* The -s option no longer suppresses "binary file matches"
- use release keyring rather than full one for validation
- Make profiling deterministic (bsc#1040589, SLE-24115)
* --files-without-match (-L) behavior reverted to again succeed
* When standard output is /dev/null, grep no longer fails when
- Drop upstreamed proc-lseek-glitch.patch
an invalid regular expression that was read from an
* grep -z would match strings it should not. To trigger the bug,
you'd have to use a regular expression including an anchor
(^ or $) and a feature like a range or a backreference, causing
With a multibyte locale, that matcher could mistakenly match a
string containing a newline. For example, this command:
would mistakenly match and print all four input bytes. After
* grep -Pz now diagnoses attempts to use patterns containing ^
and $, instead of mishandling these patterns. This problem
seems to be inherent to the PCRE API; removing this limitation
is on PCRE's maint/README wish list. Patterns can continue to
match literal ^ and $ by escaping them with \ (now needed even
* Binary files are now less likely to generate diagnostics and
more likely to yield text matches. grep now reports "Binary
file FOO matches" and suppresses further output instead of
outputting a line containing an encoding error; hence grep can
now report matching text before a later binary match.
Formerly, grep reported FOO to be binary when it found an
encoding error in FOO before generating output for FOO, which
meant it never reported both matching text and matching binary
data; this was less useful for searching text containing
OBS-URL: https://build.opensuse.org/package/show/Base:System/grep?expand=0&rev=140
- update to 3.11:
* With -P, patterns like [\d] now work again. Fixing this
has caused grep to revert to the behavior of grep 3.8, in that
patterns like \w and ^H go back to using ASCII rather
than Unicode interpretations.
However, future versions of GNU grep and/or PCRE2 are
likely to fix this and change the behavior of \w and ^H
back to Unicode again, without breaking [\d] as 3.10 did.
OBS-URL: https://build.opensuse.org/request/show/1089292
OBS-URL: https://build.opensuse.org/package/show/openSUSE:Factory/grep?expand=0&rev=89
* With -P, patterns like [\d] now work again. Fixing this
has caused grep to revert to the behavior of grep 3.8, in that
patterns like \w and  go back to using ASCII rather
than Unicode interpretations.
However, future versions of GNU grep and/or PCRE2 are
likely to fix this and change the behavior of \w and 
back to Unicode again, without breaking [\d] as 3.10 did.
OBS-URL: https://build.opensuse.org/package/show/Base:System/grep?expand=0&rev=135
* With -P, \d now matches only ASCII digits, regardless of
PCRE options/modes. The changes in grep-3.9 to make  and \w
work properly had the undesirable side effect of making \d
also match e.g., the Arabic digits: ٠١٢٣٤٥٦٧٨٩.
With grep-3.9, -P '\d+' would match that ten-digit (20-byte)
string. Now, to match such a digit, you would use \p{Nd}.
Similarly, \D is now mapped to [^0-9].
OBS-URL: https://build.opensuse.org/package/show/Base:System/grep?expand=0&rev=132
- GNU grep 3.8:
* The -P option is now based on PCRE2 instead of the older PCRE
(boo#1201803)
* egrep and fgrep commands, deprecated since release 2.5.3 (2007), now
warn that they are obsolescent and should be replaced by grep -E and
grep -F
* The confusing GREP_COLOR environment variable is now obsolescent
* Regular expressions with stray backslashes now cause warnings
* Regular expressions like [:space:] are now errors even if
POSIXLY_CORRECT is set, since POSIX now allows the GNU behavior
* In locales using UTF-8 encoding, the regular expression '.' no
longer sometimes fails to match Unicode characters
* The -s option no longer suppresses "binary file matches"
messages.
- doc: fix man page syntax errors (bsc#1201001) (forwarded request 1001672 from Andreas_Schwab)
OBS-URL: https://build.opensuse.org/request/show/1001674
OBS-URL: https://build.opensuse.org/package/show/openSUSE:Factory/grep?expand=0&rev=84
- GNU grep 3.8:
* The -P option is now based on PCRE2 instead of the older PCRE
(boo#1201803)
* egrep and fgrep commands, deprecated since release 2.5.3 (2007), now
warn that they are obsolescent and should be replaced by grep -E and
grep -F
* The confusing GREP_COLOR environment variable is now obsolescent
* Regular expressions with stray backslashes now cause warnings
* Regular expressions like [:space:] are now errors even if
POSIXLY_CORRECT is set, since POSIX now allows the GNU behavior
* In locales using UTF-8 encoding, the regular expression '.' no
longer sometimes fails to match Unicode characters
* The -s option no longer suppresses "binary file matches"
messages.
- doc: fix man page syntax errors (bsc#1201001)
OBS-URL: https://build.opensuse.org/request/show/1001672
OBS-URL: https://build.opensuse.org/package/show/Base:System/grep?expand=0&rev=123
- Update to grep 3.6
* The GREP_OPTIONS environment variable no longer affects grep's behavior.
* grep's DFA matcher performed an invalid regex transformation
that would convert an ERE like a+a+a+ to a+a+, which would make
grep a+a+a+ mistakenly match "aa".
* grep -P now reports the troublesome input filename upon PCRE execution
failure.
- werror-return-type.patch: work around gcc bug
OBS-URL: https://build.opensuse.org/request/show/850163
OBS-URL: https://build.opensuse.org/package/show/Base:System/grep?expand=0&rev=108
- Update to grep 3.3
** Changes in behavior
* The --files-without-match (-L) option now causes grep to succeed
when a file is listed, instead of when a line is selected.
** Improvements
* An over-30x performance improvement when many 'or'd expressions
share a common prefix, thanks to improvements in gnulib's dfa.c
* An additional 3-23% speed-up when searching large files, via
increased initial buffer size.
* grep now diagnoses stack overflow
- remove-backref-alt-test.patch: remove (forwarded request 663377 from Andreas_Schwab)
OBS-URL: https://build.opensuse.org/request/show/663378
OBS-URL: https://build.opensuse.org/package/show/openSUSE:Factory/grep?expand=0&rev=69
- Update to grep 3.3
** Changes in behavior
* The --files-without-match (-L) option now causes grep to succeed
when a file is listed, instead of when a line is selected.
** Improvements
* An over-30x performance improvement when many 'or'd expressions
share a common prefix, thanks to improvements in gnulib's dfa.c
* An additional 3-23% speed-up when searching large files, via
increased initial buffer size.
* grep now diagnoses stack overflow
- remove-backref-alt-test.patch: remove
OBS-URL: https://build.opensuse.org/request/show/663377
OBS-URL: https://build.opensuse.org/package/show/Base:System/grep?expand=0&rev=91
- Update to version 3.0:
* grep without -F no longer goes awry when given two or more
patterns that contain no special characters other than '\' and
also contain a subpattern like '\.' that escapes a character to
make it ordinary.
* grep no longer fails to build on PCRE versions before 8.20.
- Cleanup spec file:
* Drop support for old distributions
* Create lang subpackage
* Use fdupes to replace duplicate files with symlinks
OBS-URL: https://build.opensuse.org/request/show/456376
OBS-URL: https://build.opensuse.org/package/show/Base:System/grep?expand=0&rev=79
- Update to version 2.28:
* Improve performance for -E or -G pattern lists that are easily
converted to -F format.
* Fix performance regression with multiple patterns.
* When standard output is /dev/null, grep no longer fails when
standard input is a file in the Linux /proc file system, or when
standard input is a pipe and standard output is in append mode.
* When grep -Fo finds matches of differing length, it could
mistakenly print a shorter one. Now it prints a longest one.
- Drop upstreamed proc-lseek-glitch.patch (forwarded request 455466 from pluskalm)
OBS-URL: https://build.opensuse.org/request/show/455468
OBS-URL: https://build.opensuse.org/package/show/openSUSE:Factory/grep?expand=0&rev=62
- Update to version 2.28:
* Improve performance for -E or -G pattern lists that are easily
converted to -F format.
* Fix performance regression with multiple patterns.
* When standard output is /dev/null, grep no longer fails when
standard input is a file in the Linux /proc file system, or when
standard input is a pipe and standard output is in append mode.
* When grep -Fo finds matches of differing length, it could
mistakenly print a shorter one. Now it prints a longest one.
- Drop upstreamed proc-lseek-glitch.patch
OBS-URL: https://build.opensuse.org/request/show/455466
OBS-URL: https://build.opensuse.org/package/show/Base:System/grep?expand=0&rev=77
- Update to grep 2.27
* grep no longer reports a false match in a multibyte, non-UTF8 locale
like zh_CN.gb18030, with a regular expression like ".*7" that just
happens to match the 4-byte representation of gb18030's \uC9, the
final byte of which is the digit "7".
* grep by default now reads all of standard input if it is a pipe,
even if this cannot affect grep's output or exit status.
* grep no longer mishandles ranges in nontrivial unibyte locales.
* grep -P no longer attempts multiline matches.
* grep -m0 -L PAT FILE now outputs "FILE".
* To output ':' and tab-align the following character C, grep -T no
longer outputs tab-backspace-':'-C, an approach that has problems if
run inside an Emacs shell window.
* grep -T now uses worst-case widths of line numbers and byte offsets
instead of guessing widths that might not work with larger files.
* grep no longer reads the input in a few more cases when it is easy to
see that matching cannot succeed, e.g., 'grep -f /dev/null'. (forwarded request 444685 from Andreas_Schwab)
OBS-URL: https://build.opensuse.org/request/show/444686
OBS-URL: https://build.opensuse.org/package/show/openSUSE:Factory/grep?expand=0&rev=60
- Update to grep 2.27
* grep no longer reports a false match in a multibyte, non-UTF8 locale
like zh_CN.gb18030, with a regular expression like ".*7" that just
happens to match the 4-byte representation of gb18030's \uC9, the
final byte of which is the digit "7".
* grep by default now reads all of standard input if it is a pipe,
even if this cannot affect grep's output or exit status.
* grep no longer mishandles ranges in nontrivial unibyte locales.
* grep -P no longer attempts multiline matches.
* grep -m0 -L PAT FILE now outputs "FILE".
* To output ':' and tab-align the following character C, grep -T no
longer outputs tab-backspace-':'-C, an approach that has problems if
run inside an Emacs shell window.
* grep -T now uses worst-case widths of line numbers and byte offsets
instead of guessing widths that might not work with larger files.
* grep no longer reads the input in a few more cases when it is easy to
see that matching cannot succeed, e.g., 'grep -f /dev/null'.
OBS-URL: https://build.opensuse.org/request/show/444685
OBS-URL: https://build.opensuse.org/package/show/Base:System/grep?expand=0&rev=73
- update to 2.17
* grep -i in a multibyte locale is now typically 10 times faster
for patterns that do not contain \ or [
* grep (without -i) in a multibyte locale is now up to 7 times faster
when processing many matched lines
* grep's --mmap option was disabled in March of 2010, and began to
elicit a warning in January of 2012. Now it is completely gone.
- Reformat spec file using hints from spec-cleaner (forwarded request 223015 from mvyskocil)
OBS-URL: https://build.opensuse.org/request/show/223042
OBS-URL: https://build.opensuse.org/package/show/openSUSE:Factory/grep?expand=0&rev=45
- update to 2.17
* grep -i in a multibyte locale is now typically 10 times faster
for patterns that do not contain \ or [
* grep (without -i) in a multibyte locale is now up to 7 times faster
when processing many matched lines
* grep's --mmap option was disabled in March of 2010, and began to
elicit a warning in January of 2012. Now it is completely gone.
- Reformat spec file using hints from spec-cleaner
OBS-URL: https://build.opensuse.org/request/show/223015
OBS-URL: https://build.opensuse.org/package/show/Base:System/grep?expand=0&rev=42
The "gnulib" package contains a number of floating-point test cases
that do not work correctly with the PowerPC long double ("double double")
format. These tests "accidentally" succeeded anyway in the big-endian
variant, but are now actually failing in little-endian mode.
As is usual for gnulib, those tests end up copied into the source code
of various packages that use gnulib, including coreutils, findutils,
grep, and libunistring.
A patch to fix the tests for ppc64le has been submitted to upstream
to the bug-gnulib mailing list. We'll work with upstream of the
other affected packages to make sure the copies are refreshed.
- grep-gnulib-ppc64le.patch: Fix imported gnulib long double math
tests for little-endian PowerPC. (forwarded request 211831 from uweigand)
OBS-URL: https://build.opensuse.org/request/show/212042
OBS-URL: https://build.opensuse.org/package/show/openSUSE:Factory/grep?expand=0&rev=40
The "gnulib" package contains a number of floating-point test cases
that do not work correctly with the PowerPC long double ("double double")
format. These tests "accidentally" succeeded anyway in the big-endian
variant, but are now actually failing in little-endian mode.
As is usual for gnulib, those tests end up copied into the source code
of various packages that use gnulib, including coreutils, findutils,
grep, and libunistring.
A patch to fix the tests for ppc64le has been submitted to upstream
to the bug-gnulib mailing list. We'll work with upstream of the
other affected packages to make sure the copies are refreshed.
- grep-gnulib-ppc64le.patch: Fix imported gnulib long double math
tests for little-endian PowerPC.
OBS-URL: https://build.opensuse.org/request/show/211831
OBS-URL: https://build.opensuse.org/package/show/Base:System/grep?expand=0&rev=36
Bug fixes:
* grep -i '^$' could exit 0 (i.e., report a match) in a multi-byte
locale, even though there was no match, and the command generated
no output. E.g., seq 2 | LC_ALL=en_US.utf8 grep -il '^$' would
mistakenly print "(standard input)". Related, seq 9 |
LC_ALL=en_US.utf8 grep -in '^$' would print "2:4:6:8:10:12:14:16"
and exit 0. Now it prints nothing and exits with status of 1.
[bug introduced in grep-2.6]
* 'grep' no longer falsely reports text files as being binary on
file systems that compress contents or that store tiny contents
in metadata.
- Add current German message catalog from the translation project.
OBS-URL: https://build.opensuse.org/package/show/Base:System/grep?expand=0&rev=30
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
