- 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
  * --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

• Files Changed
• Browse Source