| 8 |
was out-of-date, and there was no check on the pcre_compile() error code |
was out-of-date, and there was no check on the pcre_compile() error code |
| 9 |
being within the table. This could lead to an OK return being given in |
being within the table. This could lead to an OK return being given in |
| 10 |
error. |
error. |
| 11 |
|
|
| 12 |
|
2. Changed the call to open a subject file in pcregrep from fopen(pathname, |
| 13 |
|
"r") to fopen(pathname, "rb"), which fixed a problem with some of the tests |
| 14 |
|
in a Windows environment. |
| 15 |
|
|
| 16 |
|
3. The pcregrep --count option prints the count for each file even when it is |
| 17 |
|
zero, as does GNU grep. However, pcregrep was also printing all files when |
| 18 |
|
--files-with-matches was added. Now, when both options are given, it prints |
| 19 |
|
counts only for those files that have at least one match. (GNU grep just |
| 20 |
|
prints the file name in this circumstance, but including the count seems |
| 21 |
|
more useful - otherwise, why use --count?) Also ensured that the |
| 22 |
|
combination -clh just lists non-zero counts, with no names. |
| 23 |
|
|
| 24 |
|
4. The long form of the pcregrep -F option was incorrectly implemented as |
| 25 |
|
--fixed_strings instead of --fixed-strings. This is an incompatible change, |
| 26 |
|
but it seems right to fix it, and I didn't think it was worth preserving |
| 27 |
|
the old behaviour. |
| 28 |
|
|
| 29 |
|
5. The command line items --regex=pattern and --regexp=pattern were not |
| 30 |
|
recognized by pcregrep, which required --regex pattern or --regexp pattern |
| 31 |
|
(with a space rather than an '='). The man page documented the '=' forms, |
| 32 |
|
which are compatible with GNU grep; these now work. |
| 33 |
|
|
| 34 |
|
|
| 35 |
Version 7.9 11-Apr-09 |
Version 7.9 11-Apr-09 |
| 36 |
--------------------- |
--------------------- |