From 28ef1abc10cfbc2c3d2747c008eb2300858d0426 Mon Sep 17 00:00:00 2001 From: Lorry Tar Creator Date: Fri, 22 Apr 2016 04:38:07 +0000 Subject: grep-2.25 --- NEWS | 984 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 984 insertions(+) create mode 100644 NEWS (limited to 'NEWS') diff --git a/NEWS b/NEWS new file mode 100644 index 0000000..1a8ff5f --- /dev/null +++ b/NEWS @@ -0,0 +1,984 @@ +GNU grep NEWS -*- outline -*- + +* Noteworthy changes in release 2.25 (2016-04-21) [stable] + +** Bug fixes + + In the C or POSIX locale, grep now treats all bytes as valid + characters even if the C runtime library says otherwise. The + revised behavior is more compatible with the original intent of + POSIX, and the next release of POSIX will likely make this official. + [bug introduced in grep-2.23] + + grep -Pz no longer mistakenly diagnoses patterns like [^a] that use + negated character classes. [bug introduced in grep-2.24] + + grep -oz now uses null bytes, not newlines, to terminate output lines. + [bug introduced in grep-2.5] + +** Improvements + + grep now outputs details more consistently when reporting a write error. + E.g., "grep: write error: No space left on device" rather than just + "grep: write error". + + +* Noteworthy changes in release 2.24 (2016-03-10) [stable] + +** Bug fixes + + 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 grep to forego its DFA + matcher and resort to using re_search. With a multibyte locale, that + matcher could mistakenly match a string containing a newline. + For example, this command: + printf 'a\nb\0' | LC_ALL=en_US.utf-8 grep -z '^[a-b]*b' + would mistakenly match and print all four input bytes. After the fix, + there is no match, as expected. + [bug introduced in grep-2.7] + + 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 inside [...]). + [bug introduced in grep-2.5] + + +* Noteworthy changes in release 2.23 (2016-02-04) [stable] + +** Bug fixes + + 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-2.21] + + grep -c no longer stops counting when finding binary data. + [bug introduced in grep-2.21] + + grep no longer outputs encoding errors in unibyte locales. + For example, if the byte '\x81' is not a valid character in a + unibyte locale, grep treats the byte as binary data. + [bug introduced in grep-2.21] + + grep -oP is no longer susceptible to an infinite loop when processing + invalid UTF8 just before a match. + [bug introduced in grep-2.22] + + --exclude and related options are now matched against trailing + parts of command-line arguments, not against the entire arguments. + This partly reverts the --exclude-related change in 2.22. + [bug introduced in grep-2.22] + + --line-buffer is no longer ineffective when combined with -l. + [bug introduced in grep-2.5] + + -xw is now equivalent to -x more consistently, with -P and with backrefs. + [bug only partially fixed in grep-2.19] + + +* Noteworthy changes in release 2.22 (2015-11-01) [stable] + +** Improvements + + Performance has improved for patterns containing very long strings, + reducing preprocessing time for an N-byte regexp from O(N^2) to + only slightly superlinear for most patterns. Before, a command like + the following would take over a minute, but now, it takes less than + a second: + : | grep -f <(seq -s '' 99999) + + When building grep, 'configure' now uses PCRE's pkg-config module for + configuration information, rather than attempting to guess it by hand. + +** Bug fixes + + A DFA matcher bug made this command mistakenly print its input line: + echo axb | grep -E '^x|x$' + Likewise for this equivalent command: + echo axb | grep -e '^x' -e 'x$' + [bug introduced in grep-2.19 ] + + grep no longer reads from uninitialized memory or from beyond the end + of the heap-allocated input buffer. This fix addressed CVE-2015-1345. + [bug introduced in grep-2.19 ] + + With -z, '.' and '[^x]' in a pattern now consistently match newline. + Previously, they sometimes matched newline, and sometimes did not. + [bug introduced in grep-2.4] + + When the JIT stack is exhausted, grep -P now grows the stack rather + than reporting an internal PCRE error. + + 'grep -D skip PATTERN FILE' no longer hangs if FILE is a fifo. + [bug introduced in grep-2.12] + + --exclude and related options are now matched against entire + command-line arguments, not against command-line components. + [bug introduced in grep-2.6] + + Fix performance degradation of grep -Fw in unibyte locales. + [bug introduced in grep-2.19 ] + + +* Noteworthy changes in release 2.21 (2014-11-23) [stable] + +** Improvements + + Performance has been greatly improved for searching files containing + holes, on platforms where lseek's SEEK_DATA flag works efficiently. + + Performance has improved for rejecting data that cannot match even + the first part of a nontrivial pattern. + + Performance has improved for very long strings in patterns. + + If a file contains data improperly encoded for the current locale, + and this is discovered before any of the file's contents are output, + grep now treats the file as binary. + + grep -P no longer reports an error and exits when given invalid UTF-8 data. + Instead, it considers the data to be non-matching. + +** Bug fixes + + grep no longer mishandles patterns that contain \w or \W in multibyte + locales. + + grep would fail to count newlines internally when operating in non-UTF8 + multibyte locales, leading it to print potentially many lines that did + not match. E.g., the command, "seq 10 | env LC_ALL=zh_CN src/grep -n .." + would print this: + 1:1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 + implying that the match, "10" was on line 1. + [bug introduced in grep-2.19] + + grep -F -x -o no longer prints an extra newline for each match. + [bug introduced in grep-2.19] + + grep in a non-UTF8 multibyte locale could mistakenly match in the middle + of a multibyte character when using a '^'-anchored alternate in a pattern, + leading it to print non-matching lines. [bug present since "the beginning"] + + grep -F Y no longer fails to match in non-UTF8 multibyte locales like + Shift-JIS, when the input contains a 2-byte character, XY, followed by + the single-byte search pattern, Y. grep would find the first, middle- + of-multibyte matching "Y", and then mistakenly advance an internal + pointer one byte too far, skipping over the target "Y" just after that. + [bug introduced in grep-2.19] + + grep -E rejected unmatched ')', instead of treating it like '\)'. + [bug present since "the beginning"] + + On NetBSD, grep -r no longer reports "Inappropriate file type or format" + when refusing to follow a symbolic link. + [bug introduced in grep-2.12] + +** Changes in behavior + + The GREP_OPTIONS environment variable is now obsolescent, and grep + now warns if it is used. Please use an alias or script instead. + + In locales with multibyte character encodings other than UTF-8, + grep -P now reports an error and exits instead of misbehaving. + + When searching binary data, grep now may treat non-text bytes as + line terminators. This can boost performance significantly. + + grep -z no longer automatically treats the byte '\200' as binary data. + +* Noteworthy changes in release 2.20 (2014-06-03) [stable] + +** Bug fixes + + grep --max-count=N FILE would no longer stop reading after the Nth match. + I.e., while grep would still print the correct output, it would continue + reading until end of input, and hence, potentially forever. + [bug introduced in grep-2.19] + + A command like echo aa|grep -E 'a(b$|c$)' would mistakenly + report the input as a matched line. + [bug introduced in grep-2.19] + +** Changes in behavior + + grep --exclude-dir='FOO/' now excludes the directory FOO. + Previously, the trailing slash meant the option was ineffective. + + +* Noteworthy changes in release 2.19 (2014-05-22) [stable] + +** Improvements + + Performance has improved, typically by 10% and in some cases by a + factor of 200. However, performance of grep -P in UTF-8 locales has + gotten worse as part of the fix for the crashes mentioned below. + +** Bug fixes + + grep no longer mishandles patterns like [a-[.z.]], and no longer + mishandles patterns like [^a] in locales that have multicharacter + collating sequences so that [^a] can match a string of two characters. + + grep no longer mishandles an empty pattern at the end of a pattern list. + [bug introduced in grep-2.5] + + grep -C NUM now outputs separators consistently even when NUM is zero, + and similarly for grep -A NUM and grep -B NUM. + [bug present since "the beginning"] + + grep -f no longer mishandles patterns containing NUL bytes. + [bug introduced in grep-2.11] + + Plain grep, grep -E, and grep -F now treat encoding errors in patterns + the same way the GNU regular expression matcher treats them, with respect + to whether the errors can match parts of multibyte characters in data. + [bug present since "the beginning"] + + grep -w no longer mishandles a potential match adjacent to a letter that + takes up two or more bytes in a multibyte encoding. + Similarly, the patterns '\<', '\>', '\b', and '\B' no longer + mishandle word-boundary matches in multibyte locales. + [bug present since "the beginning"] + + grep -P now reports an error and exits when given invalid UTF-8 data. + Previously it was unreliable, and sometimes crashed or looped. + [bug introduced in grep-2.16] + + grep -P now works with -w and -x and backreferences. Before, + echo aa|grep -Pw '(.)\1' would fail to match, yet + echo aa|grep -Pw '(.)\2' would match. + + grep -Pw now works like grep -w in that the matched string has to be + preceded and followed by non-word components or the beginning and end + of the line (as opposed to word boundaries before). Before, this + echo a@@a| grep -Pw @@ would match, yet this + echo a@@a| grep -w @@ would not. Now, they both fail to match, + per the documentation on how grep's -w works. + + grep -i no longer mishandles patterns containing titlecase characters. + For example, in a locale containing the titlecase character + 'Lj' (U+01C8 LATIN CAPITAL LETTER L WITH SMALL LETTER J), + 'grep -i Lj' now matches both 'LJ' (U+01C7 LATIN CAPITAL LETTER LJ) + and 'lj' (U+01C9 LATIN SMALL LETTER LJ). + + +* Noteworthy changes in release 2.18 (2014-02-20) [stable] + +** Bug fixes + + grep no longer mishandles patterns like [^^-~] in unibyte locales. + [bug introduced in grep-2.8] + + grep -i in a multibyte, non-UTF8 locale could be up to 200 times slower + than in 2.16. [bug introduced in grep-2.17] + + +* Noteworthy changes in release 2.17 (2014-02-17) [stable] + +** Improvements + + grep -i in a multibyte locale is now typically 10 times faster + for patterns that do not contain \ or [. + + grep (without -i) in a multibyte locale is now up to 7 times faster + when processing many matched lines. + +** Maintenance + + grep's --mmap option was disabled in March of 2010, and began to + elicit a warning in January of 2012. Now it is completely gone. + + +* Noteworthy changes in release 2.16 (2014-01-01) [stable] + +** Bug fixes + + Fix gnulib-provided maint.mk so that the release procedure described + in README-release actually does what we want. Before that fix, that + procedure resulted in a grep-2.15 tarball that would lead to a grep + binary whose --version-reported version number was 2.14.51... + + The fix to make \s and \S work with multi-byte white space broke + the use of each shortcut whenever followed by a repetition operator. + For example, \s*, \s+, \s? and \s{3} would all malfunction in a + multi-byte locale. [bug introduced in grep-2.15] + + The fix to make grep -P work better with UTF-8 made it possible for + grep to evoke a larger set of PCRE errors, some of which could trigger + an abort. E.g., this would abort: + printf '\x82'|LC_ALL=en_US.UTF-8 grep -P y + Now grep handles arbitrary PCRE errors. [bug introduced in grep-2.15] + + Handle very long lines (2GiB and longer) on systems with a deficient + read system call. + +* Noteworthy changes in release 2.15 (2013-10-26) [stable] + +** Bug fixes + + grep's \s and \S failed to work with multi-byte white space characters. + For example, \s would fail to match a non-breaking space, and this + would print nothing: printf '\xc2\xa0' | LC_ALL=en_US.UTF-8 grep '\s' + A related bug is that \S would mistakenly match an invalid multibyte + character. For example, the following would match: + printf '\x82\n' | LC_ALL=en_US.UTF-8 grep '^\S$' + [bug present since grep-2.6] + + grep -i would segfault on systems using UTF-16-based wchar_t (Cygwin) + when converting an input string containing certain 4-byte UTF-8 + sequences to lower case. The conversions to wchar_t and back to + a UTF-8 multibyte string did not take surrogate pairs into account. + [bug present since at least grep-2.6, though the segfault is new with 2.13] + + grep -E would segfault when given a regexp like '([^.]*[M]){1,2}' + for any multibyte character M. [bug introduced in grep-2.6, which would + segfault, but 2.7 and 2.8 had no problem, and 2.9 through 2.14 would + hit a failed assertion. ] + + grep -F would get stuck in an infinite loop when given a search string + that is an invalid byte sequence in the current locale and that matches + the bytes of the input twice on a line. Now grep fails with exit status 1. + + grep -P could misbehave. While multi-byte mode is only supported by PCRE + with UTF-8 locales, grep did not activate it. This would cause failures + to match multibyte characters against some regular expressions, especially + those including the '.' or '\p' metacharacters. + +** New features + + grep -P can now use a just-in-time compiler to greatly speed up matches, + This feature is transparent to the user; no flag is required to enable + it. It is only available if the corresponding support in the PCRE + library is detected when grep is compiled. + + +* Noteworthy changes in release 2.14 (2012-08-20) [stable] + +** Bug fixes + + grep -i '^$' could exit 0 (i.e., report a match) in a multi-byte locale, + even though there was no match, and the command generated no output. + E.g., seq 2 | LC_ALL=en_US.utf8 grep -il '^$' would mistakenly print + "(standard input)". Related, seq 9 | LC_ALL=en_US.utf8 grep -in '^$' + would print "2:4:6:8:10:12:14:16" and exit 0. Now it prints nothing + and exits with status of 1. [bug introduced in grep-2.6] + + 'grep' no longer falsely reports text files as being binary on file + systems that compress contents or that store tiny contents in metadata. + + +* Noteworthy changes in release 2.13 (2012-07-04) [stable] + +** Bug fixes + + grep -i, in a multi-byte locale, when matching a line containing a character + like the UTF-8 Turkish I-with-dot (U+0130) (whose lower-case representation + occupies fewer bytes), would print an incomplete output line. + Similarly, with a matched line containing a character (e.g., the Latin + capital I in a Turkish UTF-8 locale), where the lower-case representation + occupies more bytes, grep could print garbage. + [bug introduced in grep-2.6] + + --include and --exclude can again be combined, and again apply to + the command line, e.g., "grep --include='*.[ch]' --exclude='system.h' + PATTERN *" again reads all *.c and *.h files except for system.h. + [bug introduced in grep-2.6] + +** New features + + 'grep' without -z now treats a sparse file as binary, if it can + easily determine that the file is sparse. + +** Dropped features + + Bootstrapping with Makefile.boot has been broken since grep 2.6, + and was removed. + + +* Noteworthy changes in release 2.12 (2012-04-23) [stable] + +** Bug fixes + + "echo P|grep --devices=skip P" once again prints P, as it did in 2.10 + [bug introduced in grep-2.11] + + grep no longer segfaults with -r --exclude-dir and no file operand. + I.e., ":|grep -r --exclude-dir=D PAT" would segfault. + [bug introduced in grep-2.11] + + Recursive grep now uses fts for directory traversal, so it can + handle much-larger directories without reporting things like "File + name too long", and it can run much faster when dealing with large + directory hierarchies. [bug present since the beginning] + + grep -E 'a{1000000000}' now reports an overflow error rather than + silently acting like grep -E 'a\{1000000000}'. + + grep -E 'a{,10}' was not treated equivalently to grep -E 'a{0,10}'. + +** New features + + The -R option now has a long-option alias --dereference-recursive. + +** Changes in behavior + + The -r (--recursive) option now follows only command-line symlinks. + Also, by default -r now reads a device only if it is named on the command + line; this can be overridden with --devices. -R acts as before, so + use -R if you prefer the old behavior of following all symlinks and + defaulting to reading all devices. + + +* Noteworthy changes in release 2.11 (2012-03-02) [stable] + +** Bug fixes + + grep no longer dumps core on lines whose lengths do not fit in 'int'. + (e.g., lines longer than 2 GiB on a typical 64-bit host). + Instead, grep either works as expected, or reports an error. + An error can occur if not enough main memory is available, or if the + GNU C library's regular expression functions cannot handle such long lines. + [bug present since "the beginning"] + + The -m, -A, -B, and -C options no longer mishandle context line + counts that do not fit in 'int'. Also, grep -c's counts are now + limited by the type 'intmax_t' (typically less than 2**63) rather + than 'int' (typically less than 2**31). + + grep no longer silently suppresses errors when reading a directory + as if it were a text file. For example, "grep x ." now reports a + read error on most systems; formerly, it ignored the error. + [bug introduced in grep-2.5] + + grep now exits with status 2 if a directory loop is found, + instead of possibly exiting with status 0 or 1. + [bug introduced in grep-2.3] + + The -s option now suppresses certain input error diagnostics that it + formerly failed to suppress. These include errors when closing the + input, when lseeking the input, and when the input is also the output. + [bug introduced in grep-2.4] + + On POSIX systems, commands like "grep PAT < FILE >> FILE" + now report an error instead of looping. + [bug present since "the beginning"] + + The --include, --exclude, and --exclude-dir options now handle + command-line arguments more consistently. --include and --exclude + apply only to non-directories and --exclude-dir applies only to + directories. "-" (standard input) is never excluded, since it is + not a file name. + [bug introduced in grep-2.5] + + grep no longer rejects "grep -qr . > out", i.e., when run with -q + and an input file is the same as the output file, since with -q + grep generates no output, so there is no risk of infinite loop or + of an output-affecting race condition. Thus, the use of the following + options also disables the input-equals-output failure: + --max-count=N (-m) (for N >= 2) + --files-with-matches (-l) + --files-without-match (-L) + [bug introduced in grep-2.10] + + grep no longer emits an error message and quits on MS-Windows when + invoked with the -r option. + + grep no longer misinterprets some alternations involving anchors + (^, $, \< \> \B, \b). For example, grep -E "(^|\B)a" no + longer reports a match for the string "x a". + [bug present since "the beginning"] + +** New features + + If no file operand is given, and a command-line -r or equivalent + option is given, grep now searches the working directory. Formerly + grep ignored the -r and searched standard input nonrecursively. + An -r found in GREP_OPTIONS does not have this new effect. + + grep now supports color highlighting of matches on MS-Windows. + +** Changes in behavior + + Use of the --mmap option now elicits a warning. It has been a no-op + since March of 2010. + + grep no longer diagnoses write errors repeatedly; it exits after + diagnosing the first write error. This is better behavior when + writing to a dangling pipe. + + Syntax errors in GREP_COLORS are now ignored, instead of sometimes + eliciting warnings. This is more consistent with programs that + (e.g.) ignore errors in termcap entries. + +* Noteworthy changes in release 2.10 (2011-11-16) [stable] + +** Bug fixes + + grep no longer mishandles high-bit-set pattern bytes on systems + where "char" is a signed type. [bug appears to affect only MS-Windows] + + On POSIX systems, grep now rejects a command like "grep -r pattern . > out", + in which the output file is also one of the inputs, + because it can result in an "infinite" disk-filling loop. + [bug present since "the beginning"] + +** Build-related + + "make dist" no longer builds .tar.gz files. + xz is portable enough and in wide-enough use that distributing + only .tar.xz files is enough. + + +* Noteworthy changes in release 2.9 (2011-06-21) [stable] + +** Bug fixes + + grep no longer clobbers heap for an ERE like '(^| )*( |$)' + [bug introduced in grep-2.6] + + grep is faster on regular expressions that match multibyte characters + in brackets (such as '[áéíóú]'). + + echo c|grep '[c]' would fail for any c in 0x80..0xff, with a uni-byte + encoding for which the byte-to-wide-char mapping is nontrivial. For + example, the ISO-88591 locales are not affected, but ru_RU.KOI8-R is. + [bug introduced in grep-2.6] + + grep -P no longer aborts when PCRE's backtracking limit is exceeded + Before, echo aaaaaaaaaaaaaab |grep -P '((a+)*)+$' would abort. Now, + it diagnoses the problem and exits with status 2. + + +* Noteworthy changes in release 2.8 (2011-05-13) [stable] + +** Bug fixes + + echo c|grep '[c]' would fail for any c in 0x80..0xff, and in many locales. + E.g., printf '\xff\n'|grep "$(printf '[\xff]')" || echo FAIL + would print FAIL rather than the required matching line. + [bug introduced in grep-2.6] + + grep's interpretation of range expression is now more consistent with + that of other tools. [bug present since multi-byte character set + support was introduced in 2.5.2, though the steps needed to reproduce + it changed in grep-2.6] + + grep erroneously returned with exit status 1 on some memory allocation + failure. [bug present since "the beginning"] + + +* Noteworthy changes in release 2.7 (2010-09-16) [stable] + +** Bug fixes + + grep --include=FILE works once again, rather than working like --exclude=FILE + [bug introduced in grep-2.6] + + Searching with grep -Fw for an empty string would not match an + empty line. [bug present since "the beginning"] + + X{0,0} is implemented correctly. It used to be a synonym of X{0,1}. + [bug present since "the beginning"] + + In multibyte locales, regular expressions including backreferences + no longer exhibit quadratic complexity (i.e., they are orders + of magnitude faster). [bug present since multi-byte character set + support was introduced in 2.5.2] + + In UTF-8 locales, regular expressions including "." can be orders + of magnitude faster. For example, "grep ." is now twice as fast + as "grep -v ^$", instead of being immensely slower. It remains + slow in other multibyte locales. [bug present since multi-byte + character set support was introduced in 2.5.2] + + --mmap was meant to be ignored in 2.6.x, but it was instead + removed by mistake. [bug introduced in 2.6] + +** New features + + grep now diagnoses (and fails with exit status 2) commonly mistyped + regular expression like [:space:], [:digit:], etc. Before, those were + silently interpreted as [ac:eps] and [dgit:] respectively. Virtually + all who make that class of mistake should have used [[:space:]] or + [[:digit:]]. This new behavior is disabled when the POSIXLY_CORRECT + environment variable is set. + + On systems using glibc, grep can support equivalence classes. However, + whether they actually work depends on glibc's locale definitions. + +* Noteworthy changes in release 2.6.3 (2010-04-02) [stable] + +** Bug fixes + + Searching with grep -F for an empty string in a multibyte locale + would hang grep. [bug introduced in 2.6.2] + + PCRE support is once again detected on systems with + [bug introduced in 2.6.2] + + +* Noteworthy changes in release 2.6.2 (2010-03-29) [stable] + +** Bug fixes + + grep -F no longer mistakenly reports a match when searching + for an incomplete prefix of a multibyte character. + [bug present since "the beginning"] + + grep -F no longer goes into an infinite loop when it finds a match for an + incomplete (non-prefix of a) multibyte character. [bug introduced in 2.6] + + Using any of the --include or --exclude* options would cause a NULL + dereference. [bugs introduced in 2.6] + +** Build-related + + configure no longer relies on pkg-config to detect PCRE support. + + +* Noteworthy changes in release 2.6.1 (2010-03-25) [stable] + +** Bug fixes + + Character classes could cause a segmentation fault if they included a + multibyte character. [bug introduced in 2.6] + + Character ranges would not work in single-byte character sets other + than C (for example, ISO-8859-1 or KOI8-R) and some multi-byte locales. + For example, this should print "1", but would find no match: + $ echo 1 | env -i LC_COLLATE=en_US.UTF-8 grep '[0-9]' + [bug introduced in 2.6] + + The output of grep was incorrect for whole-word (-w) matches if the + patterns included a back-reference. [bug introduced in grep-2.5.2] + +** Portability + + Avoid a link failure on Solaris 8. + + +* Noteworthy changes in release 2.6 (2010-03-23) [stable] + +** Speed improvements + + grep is much faster on multibyte character sets, especially (but not + limited to) UTF-8 character sets. The speed improvement is also very + pronounced with case-insensitive matches. + +** Bug fixes + + Character classes would malfunction in multi-byte locales when using grep -i. + Examples which would print nothing for LC_ALL=en_US.UTF-8 include: + - for ranges, echo Z | grep -i '[a-z]' + - for single characters, echo Y | grep -i '[y]' + - for character types, echo Y | grep -i '[[:lower:]]' + + grep -i -o would fail to report some matches; grep -i --color, while not + missing any line containing a match, would fail to color some matches. + + grep would fail to report a match in a multibyte character set other than + UTF-8, if another match occurred earlier in the line but started in the + middle of a multibyte character. + + Various bugs in grep -P, caused by expressions such as [^b] or \S matching + newlines, were fixed. grep -P also supports the special sequences \Z and + \z, and can be combined with the command-line option -z to perform searches + on NUL-separated records. + + grep would mistakenly exit with status 1 upon error, rather than 2, + as it is documented to do. + + Using options like -1 -2 or -1 -v -2 results in two lines of + context (the last value that appears on the command line) instead + twelve (the concatenation of all the values). This is consistent + with the behavior of options -A/-B/-C. + + Two new command-line options, --group-separator=ARGUMENT and + --no-group-separator, enable further customization of the output + when -A, -B or -C is being used. + +** Other changes + + egrep accepts the -E option and fgrep accepts the -F option. If egrep + and fgrep are given another of the -E/-F/-G options, they print a more + meaningful error message. + +* Noteworthy changes in release 2.5.4 (2009-02-10) [stable] + + - This is a bugfix release. No new features. + +Version 2.5.3 + - The new option --exclude-dir allows to specify a directory pattern that + will be excluded from recursive grep. + - Numerous bug fixes + +Version 2.5.1 + - This is a bugfix release. No new features. + +Version 2.5 + - The new option --label allows to specify a different name for input + from stdin. See the man or info pages for details. + + - The internal lib/getopt* files are no longer used on systems providing + getopt functionality in their libc (e.g. glibc 2.2.x). + If you need the old getopt files, use --with-included-getopt. + + - The new option --only-matching (-o) will print only the part of matching + lines that matches the pattern. This is useful, for example, to extract + IP addresses from log files. + + - i18n bug fixed ([A-Z0-9] wouldn't match A in locales other than C on + systems using recent glibc builds + + - GNU grep can now be built with autoconf 2.52. + + - The new option --devices controls how grep handles device files. Its usage + is analogous to --directories. + + - The new option --line-buffered fflush on everyline. There is a noticeable + slow down when forcing line buffering. + + - Back references are now local to the regex. + grep -e '\(a\)\1' -e '\(b\)\1' + The last backref \1 in the second expression refer to \(b\) + + - The new option --include=PATTERN will search only matching files + when recursing in directories + + - The new option --exclude=PATTERN will skip matching files when + recursing in directories. + + - The new option --color will use the environment variable GREP_COLOR + (default is red) to highlight the matching string. + --color takes an optional argument specifying when to colorize a line: + --color=always, --color=tty, --color=never + + - The following changes are for POSIX conformance: + + . The -q or --quiet or --silent option now causes grep to exit + with zero status when a input line is selected, even if an error + also occurs. + + . The -s or --no-messages option no longer affects the exit status. + + . Bracket regular expressions like [a-z] are now locale-dependent. + For example, many locales sort characters in dictionary order, + and in these locales the regular expression [a-d] is not + equivalent to [abcd]; it might be equivalent to [aBbCcDd], for + example. To obtain the traditional interpretation of bracket + expressions, you can use the C locale by setting the LC_ALL + environment variable to the value "C". + + - The -C or --context option now requires an argument, partly for + consistency, and partly because POSIX recommends against + optional arguments. + + - The new -P or --perl-regexp option tells grep to interpret the pattern as + a Perl regular expression. + + - The new option --max-count=num makes grep stop reading a file after num + matching lines. + New option -m; equivalent to --max-count. + + - Translations for bg, ca, da, nb and tr have been added. + +Version 2.4.2 + + - Added more check in configure to default the grep-${version}/src/regex.c + instead of the one in GNU Lib C. + +Version 2.4.1 + + - If the final byte of an input file is not a newline, grep now silently + supplies one. + + - The new option --binary-files=TYPE makes grep assume that a binary input + file is of type TYPE. + --binary-files='binary' (the default) outputs a 1-line summary of matches. + --binary-files='without-match' assumes binary files do not match. + --binary-files='text' treats binary files as text + (equivalent to the -a or --text option). + + - New option -I; equivalent to --binary-files='without-match'. + +Version 2.4: + + - egrep is now equivalent to 'grep -E' as required by POSIX, + removing a longstanding source of confusion and incompatibility. + 'grep' is now more forgiving about stray '{'s, for backward + compatibility with traditional egrep. + + - The lower bound of an interval is not optional. + You must use an explicit zero, e.g. 'x{0,10}' instead of 'x{,10}'. + (The old documentation incorrectly claimed that it was optional.) + + - The --revert-match option has been renamed to --invert-match. + + - The --fixed-regexp option has been renamed to --fixed-string. + + - New option -H or --with-filename. + + - New option --mmap. By default, GNU grep now uses read instead of mmap. + This is faster on some hosts, and is safer on all. + + - The new option -z or --null-data causes 'grep' to treat a zero byte + (the ASCII NUL character) as a line terminator in input data, and + to treat newlines as ordinary data. + + - The new option -Z or --null causes 'grep' to output a zero byte + instead of the normal separator after a file name. + + - These two options can be used with commands like 'find -print0', + 'perl -0', 'sort -z', and 'xargs -0' to process arbitrary file names, + even those that contain newlines. + + - The environment variable GREP_OPTIONS specifies default options; + e.g. GREP_OPTIONS='--directories=skip' reestablishes grep 2.1's + behavior of silently skipping directories. + + - You can specify a matcher multiple times without error, e.g. + 'grep -E -E' or 'fgrep -F'. It is still an error to specify + conflicting matchers. + + - -u and -U are now allowed on non-DOS hosts, and have no effect. + + - Modifications of the tests scripts to go around the "Broken Pipe" + errors from bash. See Bash FAQ. + + - New option -r or --recursive or --directories=recurse. + (This option was also in grep 2.3, but wasn't announced here.) + + - --without-included-regex disable, was causing bogus reports .i.e + doing more harm then good. + +Version 2.3: + + - When searching a binary file FOO, grep now just reports + "Binary file FOO matches" instead of outputting binary data. + This is typically more useful than the old behavior, + and it is also more consistent with other utilities like 'diff'. + A file is considered to be binary if it contains a NUL (i.e. zero) byte. + + The new -a or --text option causes 'grep' to assume that all + input is text. (This option has the same meaning as with 'diff'.) + Use it if you want binary data in your output. + + - 'grep' now searches directories just like ordinary files; it no longer + silently skips directories. This is the traditional behavior of + Unix text utilities (in particular, of traditional 'grep'). + Hence 'grep PATTERN DIRECTORY' should report + "grep: DIRECTORY: Is a directory" on hosts where the operating system + does not permit programs to read directories directly, and + "grep: DIRECTORY: Binary file matches" (or nothing) otherwise. + + The new -d ACTION or --directories=ACTION option affects directory handling. + '-d skip' causes 'grep' to silently skip directories, as in grep 2.1; + '-d read' (the default) causes 'grep' to read directories if possible, + as in earlier versions of grep. + + - The MS-DOS and Microsoft Windows ports now behave identically to the + GNU and Unix ports with respect to binary files and directories. + +Version 2.2: + +Bug fix release. + + - Status error number fix. + - Skipping directories removed. + - Many typos fix. + - -f /dev/null fix(not to consider as an empty pattern). + - Checks for wctype/wchar. + - -E was using the wrong matcher fix. + - bug in regex char class fix + - Fixes for DJGPP + +Version 2.1: + +This is a bug fix release(see Changelog) i.e. no new features. + + - More compliance to GNU standard. + - Long options. + - Internationalization. + - Use automake/autoconf. + - Directory hierarchy change. + - Sigvec with -e on Linux corrected. + - Sigvec with -f on Linux corrected. + - Sigvec with the mmap() corrected. + - Bug in kwset corrected. + - -q, -L and -l stop on first match. + - New and improve regex.[ch] from Ulrich Drepper. + - New and improve dfa.[ch] from Arnold Robbins. + - Prototypes for over zealous C compiler. + - Not scanning a file, if it's a directory + (cause problems on Sun). + - Ported to MS-DOS/MS-Windows with DJGPP tools. + +See Changelog for the full story and proper credits. + +Version 2.0: + +The most important user visible change is that egrep and fgrep have +disappeared as separate programs into the single grep program mandated +by POSIX 1003.2. New options -G, -E, and -F have been added, +selecting grep, egrep, and fgrep behavior respectively. For +compatibility with historical practice, hard links named egrep and +fgrep are also provided. See the manual page for details. + +In addition, the regular expression facilities described in Posix +draft 11.2 are now supported, except for internationalization features +related to locale-dependent collating sequence information. + +There is a new option, -L, which is like -l except it lists +files which don't contain matches. The reason this option was +added is because '-l -v' doesn't do what you expect. + +Performance has been improved; the amount of improvement is platform +dependent, but (for example) grep 2.0 typically runs at least 30% faster +than grep 1.6 on a DECstation using the MIPS compiler. Where possible, +grep now uses mmap() for file input; on a Sun 4 running SunOS 4.1 this +may cut system time by as much as half, for a total reduction in running +time by nearly 50%. On machines that don't use mmap(), the buffering +code has been rewritten to choose more favorable alignments and buffer +sizes for read(). + +Portability has been substantially cleaned up, and an automatic +configure script is now provided. + +The internals have changed in ways too numerous to mention. +People brave enough to reuse the DFA matcher in other programs +will now have their bravery amply "rewarded", for the interface +to that file has been completely changed. Some changes were +necessary to track the evolution of the regex package, and since +I was changing it anyway I decided to do a general cleanup. + +======================================================================== +Copyright (C) 1992, 1997-2002, 2004-2016 Free Software Foundation, Inc. + + Copying and distribution of this file, with or without modification, + are permitted in any medium without royalty provided the copyright + notice and this notice are preserved. + +Permission is granted to copy, distribute and/or modify this document +under the terms of the GNU Free Documentation License, Version 1.3 or +any later version published by the Free Software Foundation; with no +Invariant Sections, with no Front-Cover Texts, and with no Back-Cover +Texts. A copy of the license is included in the "GNU Free +Documentation License" file as part of this distribution. -- cgit v1.2.1