- 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
