| 31 |
6. When --colo(u)r was used in pcregrep, only the first matching substring in |
6. When --colo(u)r was used in pcregrep, only the first matching substring in |
| 32 |
each matching line was coloured. Now it goes on to look for further matches |
each matching line was coloured. Now it goes on to look for further matches |
| 33 |
of any of the test patterns, which is the same behaviour as GNU grep. |
of any of the test patterns, which is the same behaviour as GNU grep. |
| 34 |
|
|
| 35 |
|
7. A pattern that could match an empty string could cause pcregrep to loop; it |
| 36 |
|
doesn't make sense to accept an empty string match in pcregrep, so I have |
| 37 |
|
locked it out (using PCRE's PCRE_NOTEMPTY option). By experiment, this |
| 38 |
|
seems to be how GNU grep behaves. |
| 39 |
|
|
| 40 |
|
8. The pattern (?(?=.*b)b|^) was incorrectly compiled as "match must be at |
| 41 |
|
start or after a newline", because the conditional assertion was not being |
| 42 |
|
correctly handled. The rule now is that both the assertion and what follows |
| 43 |
|
in the first alternative must satisfy the test. |
| 44 |
|
|
| 45 |
|
9. If auto-callout was enabled in a pattern with a conditional group, PCRE |
| 46 |
|
could crash during matching. |
| 47 |
|
|
| 48 |
|
10. The PCRE_DOLLAR_ENDONLY option was not working when pcre_dfa_exec() was |
| 49 |
|
used for matching. |
| 50 |
|
|
| 51 |
|
11. Unicode property support in character classes was not working for |
| 52 |
|
characters (bytes) greater than 127 when not in UTF-8 mode. |
| 53 |
|
|
| 54 |
|
12. Added the -M command line option to pcretest. |
| 55 |
|
|
| 56 |
|
|
| 57 |
Version 7.8 05-Sep-08 |
Version 7.8 05-Sep-08 |
Parent Directory
| 
Revision Log
| 
Patch