X-Recipient: archive-cygwin AT delorie DOT com
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C4BC63858C3A
Authentication-Results: sourceware.org; dmarc=none (p=none dis=none)
 header.from=SystematicSW.ab.ca
Authentication-Results: sourceware.org;
 spf=none smtp.mailfrom=systematicsw.ab.ca
X-Authority-Analysis: v=2.4 cv=Ua6U9IeN c=1 sm=1 tr=0 ts=61193d3a
 a=T+ovY1NZ+FAi/xYICV7Bgg==:117 a=T+ovY1NZ+FAi/xYICV7Bgg==:17 a=mDV3o1hIAAAA:8
 a=HOpxDCluhYJyA3V8OpUA:9 a=_FVE-zBwftR9WsbkzFJk:22
From: Cygwin grep Co-Maintainer <Brian DOT Inglis AT SystematicSW DOT ab DOT ca>
To: cygwin AT cygwin DOT com
Date: Sun, 15 Aug 2021 10:12:46 -0600
Message-Id: <announce.20210815101246.34436-1-Brian.Inglis@SystematicSW.ab.ca>
Subject: [ANNOUNCEMENT] Test: grep 3.7 (TEST)
X-CMAE-Envelope: MS4xfHTKLdfP7eDIiPOVKuzckluoQG7L2t9fxNLkE+vLzTkMObOzsRz7CVO2w7iWdt1fFxFGltaGUrv4k8+cYqnP2RvZQqPFXviVSNBrAhYtjmu14o3+6qqJ
 t97fiM6bYQUFPBYgMFim3IskSptvdExQzzKu/xbte1Upc/+NiJqMydF/hJNMMXod4eFVJ/hh5sGhB38gOUENUROXh+jT66/MZnuio7G6yZ7Y+YkB4Uk9XWOL
 0Y742adSGx0PrKgXOhc02fcGpxeLKJJMf1JqDLHBFeU=
X-Spam-Status: No, score=-1160.9 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS,
 KAM_LAZY_DOMAIN_SECURITY, KAM_SHORT, PP_MIME_FAKE_ASCII_TEXT,
 RCVD_IN_BARRACUDACENTRAL, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, 
 SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.4
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on
 server2.sourceware.org
X-BeenThere: cygwin-announce AT cygwin DOT com
X-Mailman-Version: 2.1.29
X-Mailer: Perl5 Mail::Internet v2.20
X-BeenThere: cygwin AT cygwin DOT com
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Archive: <https://cygwin.com/pipermail/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe: <https://cygwin.com/mailman/listinfo/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
Reply-To: cygwin AT cygwin DOT com
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0973966080906514688=="
Sender: "Cygwin" <cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com>

--===============0973966080906514688==
Content-Type: text/plain

The following test packages have been uploaded to the Cygwin distribution:

* grep	3.7

GNU grep searches one or more input files for lines containing a match
to a specified pattern. By default, grep outputs the matching lines. The
GNU implementation includes several useful extensions over POSIX.

Please test this Base category utility as extensively as possible
(especially if you are a Cygwin package maintainer) as this package is
used in all installations and has not been upgraded for a few years. 
I have it locally installed so it is getting used by commands, scripts,
cron jobs, and cygport builds, and has and is getting frequent exercise
with no apparent issues so far.
If no issues are reported within a couple of weeks the package will be
upgraded to current.

For more information see the project home pages:

	https://www.gnu.org/software/grep/
	https://sv.gnu.org/projects/grep/

For changes since the previous Cygwin release please see below or read
/usr/share/doc/grep/NEWS after installation; for complete details see:

	/usr/share/doc/grep/ChangeLog
	https://git.sv.gnu.org/gitweb/?p=grep.git;a=log;h=refs/tags/v3.6


Noteworthy changes in release 3.7 (2021-08-14) [stable]

* Changes in behavior

  Use of the --unix-byte-offsets (-u) option now evokes a warning.
  Since 3.1, this Windows-only option has had no effect.

* Bug fixes

  Preprocessing N patterns would take at least O(N^2) time when too many
  patterns hashed to too few buckets. This now takes seconds, not days:
  : | grep -Ff <(seq 6400000 | tr 0-9 A-J)
  [Bug#44754 introduced in grep 3.5]


Noteworthy changes in release 3.6 (2020-11-08) [stable]

* Changes in behavior

  The GREP_OPTIONS environment variable no longer affects grep's behavior.
  The variable was declared obsolescent in grep 2.21 (2014), and since
  then any use had caused grep to issue a diagnostic.

* Bug fixes

  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".
  [Bug#44351 introduced in grep 3.2]

  grep -P now reports the troublesome input filename upon PCRE execution
  failure.  Before, searching many files for something rare might fail with
  just "exceeded PCRE's backtracking limit".  Now, it also reports which file
  triggered the failure.


Noteworthy changes in release 3.5 (2020-09-27) [stable]

* Changes in behavior

  The message that a binary file matches is now sent to standard error
  and the message has been reworded from "Binary file FOO matches" to
  "grep: FOO: binary file matches", to avoid confusion with ordinary
  output or when file names contain spaces and the like, and to be
  more consistent with other diagnostics.  For example, commands
  like 'grep PATTERN FILE | wc' no longer add 1 to the count of
  matching text lines due to the presence of the message.  Like other
  stderr messages, the message is now omitted if the --no-messages
  (-s) option is given.

  Two other stderr messages now use the typical form too.  They are
  now "grep: FOO: warning: recursive directory loop" and "grep: FOO:
  input file is also the output".

  The --files-without-match (-L) option has reverted to its behavior
  in grep 3.1 and earlier.  That is, grep -L again succeeds when a
  line is selected, not when a file is listed.  The behavior in grep
  3.2 through 3.4 was causing compatibility problems.

* Bug fixes

  grep -I no longer issues a spurious "Binary file FOO matches" line.
  [Bug#33552 introduced in grep 2.23]

  In UTF-8 locales, grep -w no longer ignores a multibyte word
  constituent just before what would otherwise be a word match.
  [Bug#43225 introduced in grep 2.28]

  grep -i no longer mishandles ASCII characters that match multibyte
  characters.  For example, 'LC_ALL=tr_TR.utf8 grep -i i' no longer
  dumps core merely because 'i' matches 'İ' (U+0130 LATIN CAPITAL
  LETTER I WITH DOT ABOVE) in Turkish when ignoring case.
  [Bug#43577 introduced partly in grep 2.28 and partly in grep 3.4]

  A performance regression with -E and many patterns has been mostly fixed.
  "Mostly" as there is a performance tradeoff between Bug#22357 and Bug#40634.
  [Bug#40634 introduced in grep 2.28]

  A performance regression with many duplicate patterns has been fixed.
  [Bug#43040 introduced in grep 3.4]

  An N^2 RSS performance regression with many patterns has been fixed
  in common cases (no backref, and no use of -o or --color).
  With only 80,000 lines of /usr/share/dict/linux.words, the following
  would use 100GB of RSS and take 3 minutes. With the fix, it used less
  than 400MB and took less than one second:
    head -80000 /usr/share/dict/linux.words > w; grep -vf w w
  [Bug#43527 introduced in grep 3.4]

* Build-related

  "make dist" builds .tar.gz files again, as they are still used in
  some barebones builds.


Noteworthy changes in release 3.4 (2020-01-02) [stable]

* New features

  The new --no-ignore-case option causes grep to observe case
  distinctions, overriding any previous -i (--ignore-case) option.

* Bug fixes

  '.' no longer matches some invalid byte sequences in UTF-8 locales.
  [bug introduced in grep 2.7]

  grep -Fw can no longer false match in non-UTF-8 multibyte locales
  For example, this command would erroneously print its input line:
    echo ab | LC_CTYPE=ja_JP.eucjp grep -Fw b
  [Bug#38223 introduced in grep 2.28]

  The exit status of 'grep -L' is no longer incorrect when standard
  output is /dev/null.
  [Bug#37716 introduced in grep 3.2]

  A performance bug has been fixed when grep is given many patterns,
  each with no back-reference.
  [Bug#33249 introduced in grep 2.5]

  A performance bug has been fixed for patterns like '01.2' that
  cause grep to reorder tokens internally.
  [Bug#34951 introduced in grep 3.2]

* Build-related

  The build procedure no longer relies on any already-built src/grep
  that might be absent or broken.  Instead, it uses the system 'grep'
  to bootstrap, and uses src/grep only to test the build.  On Solaris
  /usr/bin/grep is broken, but you can install GNU or XPG4 'grep' from
  the standard Solaris distribution before building GNU Grep yourself.
  [bug introduced in grep 2.8]


Noteworthy changes in release 3.3 (2018-12-20) [stable]

* Bug fixes

  Some uses of \b in the C locale and with the DFA matcher would fail, e.g.,
  the following would print nothing (it should print the input line):
    echo 123-x|LC_ALL=C grep '.\bx'
  Using a multibyte locale, using certain regexp constructs (some ranges,
  back-references), or forcing use of the PCRE matcher via --perl-regexp (-P)
  would avoid the bug.
  [bug introduced in grep 3.2]


Noteworthy changes in release 3.2 (2018-12-20) [stable]

* Changes in behavior

  The --files-without-match (-L) option now causes grep to succeed
  when a file is listed, instead of when a line is selected.  This
  resembles what git-grep does.

* Bug fixes

  The --recursive (-r) option no longer fails on MS-Windows.
  [bug introduced in grep 2.11]

* Improvements

  An over-30x performance improvement when many 'or'd expressions
  share a common prefix, thanks to improvements in gnulib's dfa.c,
  by Norihiro Tanaka.  See gnulib commits v0.1-2110-ge648401be,
  v0.1-2111-g4299106ce, v0.1-2117-g617a60974

  An additional 3-23% speed-up when searching large files, via
  increased initial buffer size.

  grep now diagnoses stack overflow.  Before grep-2.6, the included
  regexp code would detect it.  Since 2.6, grep defaulted to using
  glibc's regexp, which lost that capability.


Noteworthy changes in release 3.1 (2017-07-02) [stable]

* Improvements

  grep '[0-9]' is now just as fast as grep '[[:digit:]]' when run
  in a multi-byte locale.  Before, it was several times slower.

* Changes in behavior

  Context no longer excludes selected lines omitted because of -m.
  For example, 'grep "^" -m1 -A1' now outputs the first two input
  lines, not just the first line.  This fixes a glitch that has been
  present since -m was added in grep 2.5.

  The following changes affect only MS-Windows platforms.  First, the
  --binary (-U) option now governs whether binary I/O is used, instead
  of a heuristic that was sometimes incorrect.  Second, the
  --unix-byte-offsets (-u) option now has no effect on MS-Windows too.


--===============0973966080906514688==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple

--===============0973966080906514688==--