On Fri, Dec 5, 2014 at 12:25 AM, Santiago Ruano Rincón <santi...@debian.org> wrote: > Hi, > > Forwarding some user's thoughts about this issue. Hope this helps to > solve this bug. > > Regards, > > Santiago > > ----- Forwarded message from Marc Lehmann <debian-report...@plan9.de> ----- > > Date: Fri, 05 Dec 2014 06:01:33 +0100 > From: Marc Lehmann <debian-report...@plan9.de>, > To: Debian Bug Tracking System <734...@bugs.debian.org>, > 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?
