9db2b6928balso 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 +0000
7375595728osc copypac from project:openSUSE:Factory package:grep revision:90, using expandDirk Mueller2024-04-10 09:05:04 +0000
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 containingDirk Mueller2024-04-10 09:04:40 +0000
d4cbb265e2Accepting request 1108777 from Base:System
Ana Guerrero
2023-09-07 19:12:00 +0000
e81a5280a0Accepting request 1104193 from home:dimstar:FactoryDirk Mueller2023-09-04 07:27:54 +0000
7815ca8e4dAccepting request 1089292 from Base:System
Dominique Leuenberger
2023-05-28 17:21:56 +0000
3ed3d1f409patterns like \w and ^H go back to using ASCII rather likely to fix this and change the behavior of \w and ^HDirk Mueller2023-05-27 08:56:55 +0000
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 +0000
eadbb2a77aAccepting request 1080166 from Base:System
Dominique Leuenberger
2023-04-21 12:15:32 +0000
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 +0000
afff5fdc7bAccepting request 1069579 from Base:System
Dominique Leuenberger
2023-03-08 13:50:58 +0000
0399a5ce73Accepting request 1069578 from home:Andreas_Schwab:Factory
Andreas Schwab
2023-03-06 10:18:56 +0000
d96df970c9Accepting request 1069487 from home:AndreasStieger:branches:Base:SystemDirk Mueller2023-03-06 09:00:51 +0000
4b4671c038Accepting request 1055273 from Base:System
Dominique Leuenberger
2023-01-07 16:15:39 +0000
858941fd15Accepting request 1054451 from home:lnussel:usrmergeDirk Mueller2023-01-04 10:54:38 +0000
e1383edf82Accepting request 1004920 from Base:System
Dominique Leuenberger
2022-09-23 12:14:15 +0000
63994663b8Accepting request 1004919 from home:Andreas_Schwab:Factory
Andreas Schwab
2022-09-20 09:05:25 +0000
e15c2fff70Accepting request 1001674 from Base:System
Dominique Leuenberger
2022-09-16 11:31:57 +0000
ebc63d0566Accepting request 1001672 from home:Andreas_Schwab:Factory
Andreas Schwab
2022-09-07 09:12:00 +0000
c668b08763Accepting request 994329 from Base:System
Dominique Leuenberger
2022-08-13 20:36:30 +0000
2e4651d6eeAccepting request 992600 from home:Andreas_Schwab:Factory
Andreas Schwab
2022-08-03 14:31:01 +0000
c6ba2f07feAccepting request 979044 from Base:System
Dominique Leuenberger
2022-05-27 22:28:02 +0000
4254629b5b- use release keyring rather than full one for validationDirk Mueller2022-05-24 19:43:06 +0000
2c80760fafAccepting request 978988 from home:coolo:branches:Base:SystemDirk Mueller2022-05-24 19:18:23 +0000
02a96d30d6Accepting request 962180 from Base:System
Dominique Leuenberger
2022-03-18 15:41:18 +0000
f97d8ce173Accepting request 962124 from home:bmwiedemann:branches:Base:System
Andreas Schwab
2022-03-16 13:02:12 +0000
4436673445Accepting request 953909 from Base:System
Dominique Leuenberger
2022-02-14 21:35:53 +0000
8e3b0ca183- use glibc-locale to reenable less common locale tests (bsc#1195390)Dirk Mueller2022-02-12 13:41:02 +0000
1343420ab0Accepting request 912393 from Base:System
Dominique Leuenberger
2021-08-24 08:53:49 +0000
cc0349ac7cAccepting request 912392 from home:Andreas_Schwab:Factory
Andreas Schwab
2021-08-16 12:20:25 +0000
2b4051f1b3Accepting request 909988 from Base:System
Dominique Leuenberger
2021-08-05 18:47:38 +0000
7b29ed8d9aAccepting request 909987 from home:Andreas_Schwab:Factory
Andreas Schwab
2021-08-03 12:27:57 +0000
993b4c7d69Accepting request 852358 from Base:System
Dominique Leuenberger
2020-12-07 13:59:52 +0000
4e25c172e4Accepting request 851470 from home:AndreasStieger:branches:Base:SystemDirk Mueller2020-12-01 14:09:11 +0000
2da8e22798Accepting request 850976 from Base:System
Dominique Leuenberger
2020-11-26 22:09:38 +0000
3402f78091Accepting request 849610 from home:lnussel:usrmoveDirk Mueller2020-11-26 10:08:54 +0000
34aeb1e3dfAccepting request 850163 from home:Andreas_Schwab:Factory
Andreas Schwab
2020-11-23 10:53:34 +0000
bc5e96c9dfAccepting request 838208 from Base:System
Dominique Leuenberger
2020-10-04 15:29:58 +0000
cc503460e4Accepting request 838206 from home:AndreasStieger:branches:Base:SystemDirk Mueller2020-09-28 09:02:25 +0000
94f472e919Accepting request 830790 from Base:System
Dominique Leuenberger
2020-09-04 08:52:21 +0000
Ana Guerrero
Dirk Mueller
Dominique Leuenberger
Andreas Schwab
Stephan Kulow
Andreas Stieger
Marcus Meissner