9db2b6928b
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 encoding errors in non-matching lines. [bug introduced in * grep -c no longer stops counting when finding binary data.
Dirk Mueller2024-04-10 09:05:21 +00:00
e00737cdeb
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 encoding errors in non-matching lines. [bug introduced in * grep -c no longer stops counting when finding binary data.
Dirk Mueller2024-04-10 09:05:21 +00:00
7375595728
osc copypac from project:openSUSE:Factory package:grep revision:90, using expand
Dirk Mueller2024-04-10 09:05:04 +00:00
ff3d0145f2
osc copypac from project:openSUSE:Factory package:grep revision:90, using expand
Dirk Mueller2024-04-10 09:05:04 +00:00
bd8584a266
- split the deprecated egrep/fgrep into a deprecated subpackage 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
Dirk Mueller2024-04-10 09:04:40 +00:00
484c03e4a9
- split the deprecated egrep/fgrep into a deprecated subpackage 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
Dirk Mueller2024-04-10 09:04:40 +00:00
d4cbb265e2
Accepting request 1108777 from Base:System
Ana Guerrero2023-09-07 19:12:00 +00:00
be3cdea447
Accepting request 1108777 from Base:System
Ana Guerrero2023-09-07 19:12:00 +00:00
e81a5280a0
Accepting request 1104193 from home:dimstar:Factory
Dirk Mueller2023-09-04 07:27:54 +00:00
9f7c973ee8
Accepting request 1104193 from home:dimstar:Factory
Dirk Mueller2023-09-04 07:27:54 +00:00
3ed3d1f409
patterns like \w and ^H go back to using ASCII rather likely to fix this and change the behavior of \w and ^H
Dirk Mueller2023-05-27 08:56:55 +00:00
763ee722ba
patterns like \w and ^H go back to using ASCII rather likely to fix this and change the behavior of \w and ^H
Dirk Mueller2023-05-27 08:56:55 +00:00
f53c211d21
- 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  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.
Dirk Mueller2023-05-18 12:01:28 +00:00
c614c688d8
- 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  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.
Dirk Mueller2023-05-18 12:01:28 +00:00
5820abc816
- update to 3.10: * 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].
Dirk Mueller2023-03-30 07:45:04 +00:00
7684608eae
- update to 3.10: * 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].
Dirk Mueller2023-03-30 07:45:04 +00:00
Dominique Leuenberger
Marcus Meissner
Ana Guerrero
Dirk Mueller
Andreas Schwab