Hi Stepan.
You've been MIA (missing in action) for a while
on this list! :-)
Good to read you back.
* On Tuesday 2005-08-23 at 12:06:13 +0200, Stepan Kasal wrote:
>
> I think that all matches should be printed, even the empty ones.
> And the same holds for --colour; if an automated system tries to
> parse the colour tags (emacs, for example), it should get all
> matches.
Do you realize that for such patterns:
-- every line matches;
-- every place on a line where there isn't
already a non-empty match, there will be
an empty match between any two adjacent
characters;
-- with --only-matching, that will just
produce a _lot_ of "filename:\n" lines;
-- with --color, this will just produce a _lot_
of human-invisible "\33[01;31m\33[K\33[m\33[K"
pairs, along with possibly more such
stuff around each non-matching character
if GREP_COLORS is so configured (and the
concern below addressed).
Of course, it can be argued that the user who
would supply such a pattern in the first place
is really asking for it, so we would be justified
to deliver.
> Basically, I'd start with the patch below.
> @@ -799,6 +799,12 @@
> PR_SGR_END_IF(grep_color);
> if (only_matching)
> fputs("\n", stdout);
> +
> + /* Make minimal progress; there may be further non-empty matches. */
> + /* XXX - Could really advance by one whole multi-octet character. */
> + if (match_size == 0)
> + match_size = 1;
> +
> beg = b + match_size;
> ibeg += match_offset + match_size; /* XXX */
> }
This alone won't work because we already did a
break on match_size == 0 by this point in the
loop, so this will be unreached. If we remove
the earlier check, then we'll have the caveats
expressed above for a lot of empty matches,
but more importantly the non-matching characters
will never have been printed in the --color case
(as opposed to the --only-matching case where
it doesn't matter).
