openSUSE Build Service

Overview Repositories Revisions Requests Users Attributes Meta

Revisions of grep

Dirk Mueller (dirkmueller) committed about 1 month ago (revision 144)

- restore texinfo macros for SLE15

Dirk Mueller (dirkmueller) committed about 1 month ago (revision 143)

- GNU grep 3.8 (jsc#PED-6579):

Dirk Mueller (dirkmueller) committed about 1 month ago (revision 142)

    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 Mueller (dirkmueller) committed about 1 month ago (revision 141)

osc copypac from project:openSUSE:Factory package:grep revision:90, using expand

Dirk Mueller (dirkmueller) committed about 1 month ago (revision 140)

- 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

buildservice-autocommit accepted request 1108777 from

Dirk Mueller (dirkmueller) 8 months ago (revision 139)

baserev update by copy to link target

Dirk Mueller (dirkmueller) accepted request 1104193 from

Dominique Leuenberger (dimstar) 9 months ago (revision 138)

- export CONFIG_SHELL=/bin/sh before running configure: results in
  the shell script (egrep/fgrep) to receive a /bin/sh shebang
  instead of requiring bash (the local shell used to build).

buildservice-autocommit accepted request 1089292 from

Dirk Mueller (dirkmueller) 12 months ago (revision 137)

baserev update by copy to link target

Dirk Mueller (dirkmueller) committed 12 months ago (revision 136)

    patterns like \w and ^H go back to using ASCII rather
    likely to fix this and change the behavior of \w and ^H

Dirk Mueller (dirkmueller) committed 12 months ago (revision 135)

- 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 &#x8; 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 &#x8;
    back to Unicode again, without breaking [\d] as 3.10 did.

buildservice-autocommit accepted request 1080166 from

Factory Maintainer (factory-maintainer) about 1 year ago (revision 134)

baserev update by copy to link target

Andreas Schwab (Andreas_Schwab) committed about 1 year ago (revision 133)

Dirk Mueller (dirkmueller) committed about 1 year ago (revision 132)

- 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 &#x8; 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].

buildservice-autocommit accepted request 1069579 from

Andreas Schwab (Andreas_Schwab) about 1 year ago (revision 131)

baserev update by copy to link target

Andreas Schwab (Andreas_Schwab) accepted request 1069578 from

Andreas Schwab (Andreas_Schwab) about 1 year ago (revision 130)

- Update to grep 3.9
  * When given multiple patterns the last of which has a back-reference,
    grep no longer sometimes mistakenly matches lines in some cases

Dirk Mueller (dirkmueller) accepted request 1069487 from

Andreas Stieger (AndreasStieger) about 1 year ago (revision 129)

GNU grep 3.9

buildservice-autocommit accepted request 1055273 from

Dirk Mueller (dirkmueller) over 1 year ago (revision 128)

baserev update by copy to link target

Dirk Mueller (dirkmueller) accepted request 1054451 from

Ludwig Nussel (lnussel) over 1 year ago (revision 127)

Replace transitional %usrmerged macro with regular version check (boo#1206798)

buildservice-autocommit accepted request 1004920 from

Andreas Schwab (Andreas_Schwab) over 1 year ago (revision 126)

baserev update by copy to link target

Andreas Schwab (Andreas_Schwab) accepted request 1004919 from

Andreas Schwab (Andreas_Schwab) over 1 year ago (revision 125)

- efgrep-warning.patch: remove warning from [ef]grep

Displaying revisions 1 - 20 of 144

Places

Revisions of grep

Places