Mail Archives: djgpp/2016/03/12/09:38:48
This is a port of GNU grep 2.24 to MSDOS/DJGPP.
This is GNU grep, the "fastest grep in the west".
GNU grep is based on a fast lazy-state deterministic matcher (about
twice as fast as stock Unix egrep) hybridized with a Boyer-Moore-Gosper
search for a fixed string that eliminates impossible text from being
considered by the full regexp matcher without necessarily having to
look at every character. The result is typically many times faster
than Unix grep or egrep. (Regular expressions containing backreferencing
will run more slowly, however.)
DJGPP specific changes.
=======================
- There are no DJGPP specific user visible changes.
- The port has been tested by using it. I have used it on WinXP only.
It has worked flawlessly. I do not konw if this will ever be the case on
FreeDOS. I have never used/tested them in that environment.
- The port has been configured and compiled on WinXP SP3 and Win98SE using
gcc530b and bnu226br3. There is no guarantee that this may be possible
with any other DOS-like OS. Due to the massive use of long file names it
will not be possible to configure and compile without LFN support.
- The port does not provide NLS support.
- The port has been configured with perl-regexp (pcre) support enabled.
This means that you will have to install pcre libray available as:
ftp://ftp.delorie.com/pub/djgpp/current/v2tk/pcre838b.zip
if you decide to compile the the preconfigured sources. If you prefer
to disable the pcre support you will have to reconfigure and recompile
the sources again, but this time passing the "no-pcre" command line
option to config.bat. The zip file contains only the one build with
perl-regexp support enabled.
I have tried to configure with pcr1021b but the configuration step failed,
so that pcre838b has been used.
As usual, all djgpp specific files (diffs, README files, etc.) are stored in
the /djgpp directory. The sources have been configured to be build in the
/_build directory. If for some reason it does not work for you, delete its
contents and configure from scratch again.
For further information about GNU grep please read the info docs and NEWS file.
This is an verbatim extract of the NEWS file (multi-byte specific features are
not supported by the DJGPP port):
-------------------------------------------------------------------------------
* 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]
-------------------------------------------------------------------------------
The port consists of the usual three packages produced using djdev205
that can be downloaded from ftp.delorie.com and mirrors as (time stamp 2016-03-11):
grep 2.24 binaries, info and man format documentation:
ftp://ftp.delorie.com/pub/djgpp/beta/v2gnu/grep224b.zip
grep 2.24 dvi, html, pdf and ps format documentation:
ftp://ftp.delorie.com/pub/djgpp/beta/v2gnu/grep224d.zip
grep 2.24 source:
ftp://ftp.delorie.com/pub/djgpp/beta/v2gnu/grep224s.zip
Send grep specific bug reports to <bug-grep AT gnu DOT org>.
Send suggestions and bug reports concerning the DJGPP port to
comp.os.msdos.djgpp or <djgpp AT delorie DOT com>.
If you are not sure if the failure is really a grep failure
or a djgpp specific failure, report it here and *not* to
<bug-grep AT gnu DOT org>.
Enjoy.
Guerrero, Juan Manuel <juan DOT guerrero AT gmx DOT de>
- Raw text -