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

[Santiago Ruano Rincón]

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.

The choice of "a) data corruption" over the alternatives is puzzling, as
the default settings of grep do not change the background colour, so the
"fix" (that corrupts the output) is entirely unnecessary when the goal is
just to change the text colour.

That is, setting "GREP_COLORS=ne" by default should always be safe unless
the user configured a backgorund colour change, or I am missing something
about the defaults.

Even if background colours were the default, there are a multitude of
workarounds that are all better than a) or b) above, for example, one
could output every character twice, once with the default bg + backspace +
character with coloured background. I don't know on which terminals this
might break, but unless your terminal is one line high, this should work
in vt10x emulators.

Another alternative would be to force a scroll before changing attributes
(move down/move up), which should give results visually indistinguishable
from the correct solution under all normal usage patterns.

I didn't think long about this problem, there might be even better
solutions.

So, in short, grep should simply change to sane defaults ("GREP_COLORS=ne",
leaving the problem to the user who configures his/her own GREP_COLORS),
or implement a suitable workaround (such as forcing a scroll with default
attributes).

Both of these would result in no data corruption. The first will result in
(presumably) ugly background colour changes if the user configures that,
the second should always work. Some experimentation might be in order, but
surely grep can do better than just corrupt the search results.


-- System Information:
Debian Release: 7.5
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable'), (500, 'testing'), (500, 
'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16-3-amd64 (SMP w/12 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages grep depends on:
ii  dpkg          1.16.15
ii  install-info  4.13a.dfsg.1-10
ii  libc6         2.19-1
ii  libpcre3      1:8.31-5

grep recommends no packages.

grep suggests no packages.

-- no debconf information


----- End forwarded message -----