bug#15444: address@hidden: Bug#734147: grep: colorisation corrupts character at end of line]

[Jim Meyering]

On Fri, Dec 5, 2014 at 12:25 AM, Santiago Ruano Rincón
<address@hidden> wrote:
> Hi,
>
> Forwarding some user's thoughts about this issue. Hope this helps to
> solve this bug.
>
> Regards,
>
> Santiago
>
> ----- Forwarded message from Marc Lehmann <address@hidden> -----
>
> Date: Fri, 05 Dec 2014 06:01:33 +0100
> From: Marc Lehmann <address@hidden>,
> To: Debian Bug Tracking System <address@hidden>,
> Subject: Bug#734147: grep: colorisation corrupts character at end of line
> X-Mailer: reportbug 6.4.4
>
> Package: grep
> Version: 2.21-1
> Followup-For: Bug #734147
>
> Dear Maintainer,
>
> seeing that the bug is still in grep, here are some thoughts:
>
> Foremost, this is a bug in grep, but it is also a bug in xterm (and rxvt),
> which claim to emulate vt102 behaviour, but both vt100 and vt102 behave
> like urxvt, namely space at the end of the line. At least, thats what the
> ROM image of either emulator does when run in a hardware simulator and fed
> with the example.
>
> As for grep, you can currently choose between a) data corruption and b)
> annoying background colour bars IFF the user configures it.

Thank you for forwarding that.
However, note that there is another downside to making the
proposed change, not just "annoying background color bars...".

Currently, when grep matches a line containing a mix of
\r and \t bytes, it does what most expect/desire (with the
HT replacing each preexisting glyph with a space):

  $ printf 'asdfqwerzxcv\rASDF\tZXCV\n'|grep --color A
  ASDF    ZXCV

If we were to change grep so that it would no longer print
those offending \e[K codes, that same command would no
longer overwrite:

  $ printf 'asdfqwerzxcv\rASDF\tZXCV\n'|grep --color A
  ASDFqwerZXCV

I think the underlying issue is that we want grep's --color option
to be "safe", i.e., we want grep to stop conspiring with common
terminal emulators to mangle certain output lines.
Currently, it handles the \r...\t case at the expense of mangling
any match that begins in the rightmost column of your terminal.
The \r...\t issue is just one example of what can happen when
a tool prints arbitrary control sequences to a terminal, so
it feels like a red herring.  The mangling of real matches can
happen even with carefully sanitized input. That is more
problematic.

As such, I am leaning towards making the default be the
same as what setting "GREP_COLORS=ne" does now.

Opinions to the contrary?