Bug#734147: grep: colorisation corrupts character at end of line
Package: grep Version: 2.14-1 Severity: normal Dear Maintainer, When grep is asked to colorise matches (e.g. grep --color=tty), it outputs an sgr sequence to switch to (e.g.) red text colour, followed by a clear to end of screen. (apparently, this is the patch that implements that: http://git.savannah.gnu.org/cgit/grep.git/commit/src/grep.c?id=1eb74b3a38f16192097fc1d51a9b219165c540aa) The problem is that this corrupts the character before the match when the match happens to be at the end of the line. e.g. when grep prints "1234\e[1m\e[K", in a terminal that has 4 columns, it expects the first line to be 1234, and the second be a coloured : 1234 However, the result in xterm is: 123u uuu While the result in urxvt is: 123 i.e. in xterm a character is missing, in urxvt it gets cleared. this is because the cursor is at the end of the line for the last character of the line, so a clear to end of screen erases that character. (apparently xterm and urxvt disagree on whether to clear the cursor-past-margin flag, but they do agree that clearing to end of screen clears from the visible cursor position onward). -- System Information: Debian Release: 7.1 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.10-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.10 ii install-info 4.13a.dfsg.1-10 ii libc6 2.17-93 grep recommends no packages. Versions of packages grep suggests: ii libpcre3 1:8.31-2 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#734147: grep: colorisation corrupts character at end of line
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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#734147: grep: colorisation corrupts character at end of line
Control: forwarded -1 http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15444 Control: merge 477461 477463 477464 712024 -1 El 04/01/14 a las 11:29, Marc Lehmann escribió: > Package: grep > Version: 2.14-1 > Severity: normal > > Dear Maintainer, > > When grep is asked to colorise matches (e.g. grep --color=tty), it outputs > an sgr sequence to switch to (e.g.) red text colour, followed by a clear > to end of screen. > > (apparently, this is the patch that implements that: > http://git.savannah.gnu.org/cgit/grep.git/commit/src/grep.c?id=1eb74b3a38f16192097fc1d51a9b219165c540aa) > > The problem is that this corrupts the character before the match when the > match happens to be at the end of the line. > > e.g. when grep prints "1234\e[1m\e[K", in a terminal that has 4 > columns, it expects the first line to be 1234, and the second be a > coloured : > >1234 > > > However, the result in xterm is: > >123u >uuu > > While the result in urxvt is: > >123 > > > i.e. in xterm a character is missing, in urxvt it gets cleared. this is > because the cursor is at the end of the line for the last character of the > line, so a clear to end of screen erases that character. > > (apparently xterm and urxvt disagree on whether to clear the > cursor-past-margin flag, but they do agree that clearing to end of screen > clears from the visible cursor position onward). Hi, Merging this bug to other similar reports. Thanks for reporting this issue, Santiago -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
