GNU bug report logs -
#15444
One character can be lost if colors are enabled
Previous Next
To reply to this bug, email your comments to 15444 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-grep <at> gnu.org:
bug#15444; Package
grep.
(Mon, 23 Sep 2013 13:35:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Jaroslav Skarvada <jskarvad <at> redhat.com>:
New bug report received and forwarded. Copy sent to
bug-grep <at> gnu.org.
(Mon, 23 Sep 2013 13:35:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Reproducer:
$ printf 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx1234xxxxxxxxx\n' | grep 1234 --color=always
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx123xxxxxxxxx
This can be reproduced at least on xterm and linux console,
but it works on xfce4-terminal and konsole (at least).
The EL command (\E[K) is sent to clear the line. The VT100
terminal autowraps when the 81th character is received and the
EL command is not counted as a character. So if 80 characters
are received, it waits on the 80th character and the following
EL command erases characters from the current one to the end
of line (i.e. the last character on the line).
Workaround is to use GREP_COLORS=ne.
The original Red Hat bugzilla that contains discussion with
the xterm upstream:
http://bugzilla.redhat.com/show_bug.cgi?id=1006310
Information forwarded
to
bug-grep <at> gnu.org:
bug#15444; Package
grep.
(Mon, 23 Sep 2013 17:37:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 15444 <at> debbugs.gnu.org (full text, mbox):
On Mon, Sep 23, 2013 at 6:34 AM, Jaroslav Skarvada <jskarvad <at> redhat.com> wrote:
> printf 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx1234xxxxxxxxx\n' | grep 1234 --color=always
Thank you for the report.
I confirm that setting GREP_COLORS=ne is a work-around. Does that
have unwelcome side effects on any other type of terminal that you've
tried?
Information forwarded
to
bug-grep <at> gnu.org:
bug#15444; Package
grep.
(Tue, 24 Sep 2013 07:42:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 15444 <at> debbugs.gnu.org (full text, mbox):
----- Original Message -----
> On Mon, Sep 23, 2013 at 6:34 AM, Jaroslav Skarvada <jskarvad <at> redhat.com>
> wrote:
> > printf
> > 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx1234xxxxxxxxx\n'
> > | grep 1234 --color=always
>
> Thank you for the report.
> I confirm that setting GREP_COLORS=ne is a work-around. Does that
> have unwelcome side effects on any other type of terminal that you've
> tried?
>
It's only workaround, I think it cannot be used by default, because
it can have undesired effect if custom background is used, e.g.:
$ printf 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx12345x\n' | GREP_COLORS='sl=01;41:ne' grep --color=always 1234
(on some terms you need to repeat this more times until the term
vertically scrolls to see the difference w/wo 'ne').
From the discussion in the original report it seems, the reported
xterm autowrap behaviour is DEC VT100 feature (for me historical bug
that became feature) and could be deduced from the xenl terminfo
capability. But as e.g. libvte interprets this different way, there
is probably no simple fix (even in case grep would read terminfo).
Maybe the xterm upstream will come with some idea
Jaroslav
Information forwarded
to
bug-grep <at> gnu.org:
bug#15444; Package
grep.
(Fri, 05 Dec 2014 08:27:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 15444 <at> debbugs.gnu.org (full text, mbox):
Hi,
Forwarding some user's thoughts about this issue. Hope this helps to
solve this bug.
Regards,
Santiago
----- Forwarded message from Marc Lehmann <debian-reportbug <at> plan9.de> -----
Date: Fri, 05 Dec 2014 06:01:33 +0100
From: Marc Lehmann <debian-reportbug <at> plan9.de>,
To: Debian Bug Tracking System <734147 <at> 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.
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 -----
Information forwarded
to
bug-grep <at> gnu.org:
bug#15444; Package
grep.
(Fri, 05 Dec 2014 20:26:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 15444 <at> debbugs.gnu.org (full text, mbox):
On Fri, Dec 5, 2014 at 12:25 AM, Santiago Ruano Rincón
<santiago <at> 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-reportbug <at> plan9.de> -----
>
> Date: Fri, 05 Dec 2014 06:01:33 +0100
> From: Marc Lehmann <debian-reportbug <at> plan9.de>,
> To: Debian Bug Tracking System <734147 <at> 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?
Information forwarded
to
bug-grep <at> gnu.org:
bug#15444; Package
grep.
(Wed, 13 Jul 2016 22:01:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 15444 <at> debbugs.gnu.org (full text, mbox):
As of today, the test case
echo "
1234" | grep --color=auto '[1-9]'
(80 spaces and 1234)
still fails in (u)xterm. Any resolution in sight?
(Sorry for not providing any opinion of _how_ to resolve it technically
at the moment; I'm not good enough for that. It is just the bug has been
kind of disturbing me for a few years already...)
Information forwarded
to
bug-grep <at> gnu.org:
bug#15444; Package
grep.
(Wed, 13 Jul 2016 22:38:01 GMT)
Full text and
rfc822 format available.
Message #23 received at submit <at> debbugs.gnu.org (full text, mbox):
Leon wrote:
>> As of today, the test case
>>
>> echo "
>> 1234" | grep --color=auto '[1-9]'
>> (80 spaces and 1234)
>>
>> still fails in (u)xterm. Any resolution in sight?
Does the following also fail for you? It uses python instead of
(difficult to see in email) explicit spaces to get the 80 spaces.
python2 -c 'print " " * 80, 1234' | grep --color=auto '[1-9]'
However they both appear to fail in uxterm, IF I have the
terminal set to 80 columns wide. If the terminal is wider,
then I can see the red 1234 out in "right field". For example,
if the terminal is 84 chars wide, I can see the red "12", but
not the "34", unless the terminal is at least 86 chars wide.
If I invoke uxterm with the -cm option, to disable ANSI color
sequences, then the extra 2 bytes aren't needed, and a terminal
that's 84 chars wide will show all, uncolored, four "1234" numbers.
In xterm, I need a terminal 82 chars wide (not 84 like uxterm)
to see the red "12", and I need a terminal of 84 chars wide
(not 86 like uxterm) to see all four red numbers "1234".
I did not double check the perfection of the above details,
so might be off by one or two, here or there.
But I'd guess that this might be a "bug" (unexpected feature)
in the terminal emulator's handling of ANSI color escape
sequences, rather than a bug in grep.
--
Paul Jackson
pj <at> usa.net
Information forwarded
to
bug-grep <at> gnu.org:
bug#15444; Package
grep.
(Thu, 14 Jul 2016 15:38:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 15444 <at> debbugs.gnu.org (full text, mbox):
Leon Meier wrote:
> As of today, the test case [...] still fails in (u)xterm.
> Any resolution in sight?
I tried to reproduce, and indeed, it fails on xterm (without the 'ne' grep
option), but not in gnome-terminal.
Does that mean that this is an xterm bug again and not a grep bug?
See this:
http://wjd.nu/files/2016/07/debian-bug-456943.png?view
This works both in gnome-terminal and xterm:
python -c 'print(" "*'$COLUMNS'+"1234")' |
GREP_COLORS=ne grep --color=auto '[1-9]'
This works in gnome-terminal and *fails* in xterm:
python -c 'print(" "*'$COLUMNS'+"1234")' |
grep --color=auto '[1-9]'
Versions (Ubuntu, Trusty, latest):
gnome-terminal 3.6.2-0ubuntu1
grep 2.16-1
xterm 297-1ubuntu1
Greetings,
Walter Doekes
Information forwarded
to
bug-grep <at> gnu.org:
bug#15444; Package
grep.
(Thu, 14 Jul 2016 15:40:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 15444 <at> debbugs.gnu.org (full text, mbox):
> Does the following also fail for you? It uses python instead of
> (difficult to see in email) explicit spaces to get the 80 spaces.
Sorry; in my previous e-mail there was a wraparound induced by the e-mail composer. This one is hopefully better:
$ echo " "| grep --color=always '[1-9]'
> python2 -c 'print " " * 80, 1234' | grep --color=auto '[1-9]'
This one does work for a standard 80-char-wide (u)xterm.
Information forwarded
to
bug-grep <at> gnu.org:
bug#15444; Package
grep.
(Thu, 14 Jul 2016 21:23:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 15444 <at> debbugs.gnu.org (full text, mbox):
On 2016-07-14 09:02:48 +0200, Walter Doekes wrote:
> Leon Meier wrote:
> > As of today, the test case [...] still fails in (u)xterm.
> > Any resolution in sight?
>
> I tried to reproduce, and indeed, it fails on xterm (without the 'ne' grep
> option), but not in gnome-terminal.
>
> Does that mean that this is an xterm bug again and not a grep bug?
It is GNOME Terminal that is buggy, so that the grep bug is not
visible.
--
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Information forwarded
to
bug-grep <at> gnu.org:
bug#15444; Package
grep.
(Fri, 15 Jul 2016 05:19:01 GMT)
Full text and
rfc822 format available.
Message #35 received at submit <at> debbugs.gnu.org (full text, mbox):
Leon wrote:
>> Sorry; in my previous e-mail there was a wraparound induced by the e-mail composer. This one is hopefully better:
>> $ echo " "| grep --color=always '[1-9]'
>>
>> python2 -c 'print " " * 80, 1234' | grep --color=auto '[1-9]'
>>
>> This one does work for a standard 80-char-wide (u)xterm.
The above two commands are not the same.
That echo command seems to emit 79 spaces, followed by one newline (but no numbers at all ??)
That (my) python2 command emits 81 spaces, the four numbers, and a newline.
Try this one (fixing my off-by-one space count, as the ',' comma in print args emits a space of its own):
python2 -c 'print " " * 79, 1234' | grep --color=always '[1-9]'
And try this one (fixing what I guess is your accidental omission of one space and the four numbers):
echo " 1234"| grep --color=always '[1-9]'
I get the same results from either of the last two test cases above, with the red "1234" numbers
NOT appearing in an 80 wide xterm or uxterm, but appearing ok if I widen the terminal.
--
Paul Jackson
pj <at> usa.net
Information forwarded
to
bug-grep <at> gnu.org:
bug#15444; Package
grep.
(Mon, 25 Mar 2024 15:33:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 15444 <at> debbugs.gnu.org (full text, mbox):
On 2016-07-14 14:22:15 -0700, Vincent Lefevre wrote:
> On 2016-07-14 09:02:48 +0200, Walter Doekes wrote:
> > Leon Meier wrote:
> > > As of today, the test case [...] still fails in (u)xterm.
> > > Any resolution in sight?
> >
> > I tried to reproduce, and indeed, it fails on xterm (without the 'ne' grep
> > option), but not in gnome-terminal.
> >
> > Does that mean that this is an xterm bug again and not a grep bug?
>
> It is GNOME Terminal that is buggy, so that the grep bug is not
> visible.
A solution for "grep" would be to add a space+backspace before the
escape sequence.
Testcase:
for i in `seq 5` ; do printf "%0$(($(tput cols)+i-5))dab \bc\n" ; done | \
GREP_COLORS="mt=41;97:ne" grep --color c
This works fine in Xterm, giving on a 80-column terminal:
0000000000000000000000000000000000000000000000000000000000000000000000000000abc
00000000000000000000000000000000000000000000000000000000000000000000000000000abc
000000000000000000000000000000000000000000000000000000000000000000000000000000abc
0000000000000000000000000000000000000000000000000000000000000000000000000000000abc
00000000000000000000000000000000000000000000000000000000000000000000000000000000abc
where only the "c" has the red background.
However, this triggers the bug in GNOME Terminal (and other
libvte-based terminals):
0000000000000000000000000000000000000000000000000000000000000000000000000000abc
00000000000000000000000000000000000000000000000000000000000000000000000000000ac
000000000000000000000000000000000000000000000000000000000000000000000000000000abc
0000000000000000000000000000000000000000000000000000000000000000000000000000000abc
00000000000000000000000000000000000000000000000000000000000000000000000000000000abc
--
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Information forwarded
to
bug-grep <at> gnu.org:
bug#15444; Package
grep.
(Mon, 25 Mar 2024 17:03:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 15444 <at> debbugs.gnu.org (full text, mbox):
On 2024-03-25 15:49:52 +0100, Vincent Lefevre wrote:
> A solution for "grep" would be to add a space+backspace before the
> escape sequence.
An additional note: One of the following is needed:
* Detect the end of line (this may be tricky) and split the coloring
into 2 parts (each one with space + backspace + escape sequence)
at this point. If this detection is incorrect, then the background
problem would still be visible, but with no major drawbacks.
* Split the coloring so that each matching character gets a space +
backspace + escape sequence. I think that this is acceptable since
this trick should be used only when the output is a tty (i.e. it
is not redirected to a file / not piped to a pager or something
else).
--
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Information forwarded
to
bug-grep <at> gnu.org:
bug#15444; Package
grep.
(Tue, 26 Mar 2024 17:48:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 15444 <at> debbugs.gnu.org (full text, mbox):
On 3/25/24 08:49, Vincent Lefevre wrote:
> This works fine in Xterm, giving on a 80-column terminal:
>
> ...
>
> However, this triggers the bug in GNOME Terminal (and other
> libvte-based terminals):
That's not good. Is there some escape sequence that will work on both
xterm and libvte? I assume the space+backspace trick you suggested later
assumes xterm behavior.
Information forwarded
to
bug-grep <at> gnu.org:
bug#15444; Package
grep.
(Tue, 26 Mar 2024 23:51:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 15444 <at> debbugs.gnu.org (full text, mbox):
On 2024-03-26 11:47:26 -0600, Paul Eggert wrote:
> On 3/25/24 08:49, Vincent Lefevre wrote:
> > This works fine in Xterm, giving on a 80-column terminal:
> >
> > ...
> > However, this triggers the bug in GNOME Terminal (and other
> > libvte-based terminals):
>
> That's not good. Is there some escape sequence that will work on
> both xterm and libvte? I assume the space+backspace trick you
> suggested later assumes xterm behavior.
I've eventually found that this works in xterm only because
I have the reverseWrap option set (a setting I've had since
at least June 1996... so that I forgot about it). In the past,
I think that I set it in order to be able to go backward to
the previous line in cooked mode. But this is not the default
behavior in xterm (at least nowadays).
It could still be nice to have this trick in grep as an *option*
for GREP_COLORS (just like one already has "ne").
But perhaps the best solution would be to make terminals implement
new escape sequences to enable/disable the use of the default
background color (instead of the current background color, which
is the current behavior and the cause of this bug) for the new line
when scrolling, or something similar.
--
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Information forwarded
to
bug-grep <at> gnu.org:
bug#15444; Package
grep.
(Wed, 27 Mar 2024 08:16:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 15444 <at> debbugs.gnu.org (full text, mbox):
Hello,
VTE co-developer here. (VTE, a.k.a. libvte is the terminal emulation
widget behind GNOME Terminal and several other terminal emulator
apps.)
Note that this very bug is also filed at https://savannah.gnu.org/bugs/?36831 .
---
The "background color erase" ("bce") feature of most terminals suffers
from a fundamental design flaw. You cannot "just print" some piece of
text containing non-default background color, and expect it to appear
on the screen correctly.
By "just printing" what I mean is that you don't go into the business
of querying the terminal size, tracking the cursor position, knowing
which characters will be double wide, computing where the line would
wrap to the next one, etc. I'm only considering simple apps that print
messages using printf() or similar, like grep does.
The problem is that if you're at the bottom of the screen and
autowrapping occurs, the entire new line is added with the currently
active background color, which might not be the terminal's default
background color. If that new line isn't filled with text entirely
then the rest remains with that color.
The workaround applied by "grep" by default is to switch back to the
default background color and emit the sequence that clears to the end
of the line. This, while fixes the background color issue (apart from
a possible temporary flicker if the terminal doesn't process grep's
output in a single step and updates its display in the middle),
introduces a different bug: possibly chopping off one letter of
output.
For the sake of explaining it, assume 80 columns numbered from 1 to
80. The way terminals behave is: After printing 78 chars the cursor is
in column 79. After printing one more char the cursor is in column 80.
After printing the 80th char in the 80th column, the cursor remains in
column 80 (over this newly printed character) (*), but a special flag
is set, in Xterm's source I believe it's called "do_wrap", it denotes
that the next character will wrap to the next line.
((*) VTE hides the cursor in this case, but it's irrelevant for this bug.)
Some operations, like handling a backspace, or clearing to the end of
the line unfortunately don't take this "do_wrap" flag into account.
That is, after printing 80 characters and being in the "do_wrap"
state, the "clear to end of line" escape sequence only checks that the
cursor is in column 80, therefore clears everything in column 80 and
its right (i.e. column 80 only). And it also clears the "do_wrap"
flag.
Perhaps about 8-10 years ago I talked about this conceptual problem
with the developer of xterm and ncurses, and he wasn't interested in
doing anything about the situation. I, however, still was.
---
In VTE I made two modifications, i.e. at two places we intentionally
deviate from the standard behavior to fix this nonsense and make grep
work as expected. One of the workarounds is for when grep is asked to
emit that clear-to-eol, one is for when it isn't.
In https://bugzilla.gnome.org/show_bug.cgi?id=740789 (2014) I changed
the behavior of the clear-to-eol escape sequence. If in that "do_wrap"
state then it doesn't clear the last character, nor this "do_wrap"
state, it becomes no-op.
In https://bugzilla.gnome.org/show_bug.cgi?id=754596 (2015-2017) I
modified the bce feature to fill the newly appearing line with the
current background only if scrolling occurs due to an explicit newline
or escape sequence, but not when it occurs to text autowrapping, in
which case we use the terminal's default background color.
Neither of these changes cause any problem in real life that we're
aware of. The first iteration of the bce change in 2015 had some
problem that I fixed in 2017. We haven't received any bugreport since
then about either of these intentional deviations from the standard.
The result is that grep's output renders correctly in VTE, no matter
if you use its "ne" feature or not.
However, the goal should be to fix it in all terminals out there.
---
So, what should "grep" do?
Its maintainers, or anyone interested in pushing this through (it's
not going to be me, sorry) could talk to Xterm's and other terminals'
authors to change the default, or find a solution. They could point
out that these two workarounds in VTE have turned out to be fine, and
suggest to change the default behavior to these. (However, I wouldn't
expect everyone to agree. I'd expect that many of these folks would
insist on strictly adhering to the standards, rather than
acknowledging that the standard is conceptually broken and being okay
with deviating from it.)
As for clear-to-eol, I think urxvt kept the official behavior, but
added the same sequence with numeric parameter 3, i.e. \e[3K, to
perform the slightly modified (fixed) behavior. Could be a reasonable
route to go down.
As for the immediate future, i.e. assuming that grep maintainers don't
want to or don't succeed in driving such a change across leading /
reference terminals (probably most notably Xterm) and then wait for
years for this to become widespread, the question is: Would you rather
have a wrong background color, or a letter missing? I'm puzzled how
upstream grep, for many-many years, has chosen to possibly chop off a
letter as its default behavior, I firmly believe that it's by far the
worse of the two.
Or start thinking about brand new workarounds. Like Vincent's idea
with a space + backspace. Or space + backspace + clear-to-eol. Or
space + clear-to-eol. These _could_ be robust against issues at the
right margin. Obviously these brainstorming ideas I'm randomly
throwing in now have to be tested carefully across many popular
terminals. Maybe with both possible values of Xterm's reverse
wraparound, maybe with only the default because the other value causes
ncurses corruptions in Xterm
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067679#10) so you
can't really count on that anyway.
Also, I'm not sure if currently grep emits clear-to-eol wherever the
background color changes within a line, or at the end of the line
after reverting to the terminal's default. Workarounds involving space
/ backspace chars probably only work with the latter approach.
Also, a minor issue, but could be important / annoying to some users:
printing space / backspace can modify how trailing spaces get
copy-pasted in some terminals. It would be nice to copy-paste grep's
output exactly as it appeared in the file. But if that's the price to
pay to fix the other two problems, probably it's still the least bad.
e.
Information forwarded
to
bug-grep <at> gnu.org:
bug#15444; Package
grep.
(Wed, 27 Mar 2024 20:36:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 15444 <at> debbugs.gnu.org (full text, mbox):
On 3/27/24 02:15, Egmont Koblinger wrote:
> The problem is that if you're at the bottom of the screen and
> autowrapping occurs, the entire new line is added with the currently
> active background color, which might not be the terminal's default
> background color. If that new line isn't filled with text entirely
> then the rest remains with that color.
Thanks for the detailed analysis. Surely the issue quoted above is the
main problem. That is, grep (and other programs) should be able to
output color changes without knowing or worrying about line length, and
shouldn't have to do any hack like what grep does now, where it switches
back to the default background color and clears to the end of the line
(and here I'm talking about either the current grep behavior, or the
\e[3K of urxvt).
Shouldn't there be a better way to do things - perhaps a new escape
sequence that grep etc. can use, which says "I don't know what the
physical line length is and I don't care"?
> I'm puzzled how
> upstream grep, for many-many years, has chosen to possibly chop off a
> letter as its default behavior
A good chunk of this is plain caution, as you can see from the bug
report. No matter what we do it'll be "wrong" for some users and we've
lacked the time or desire to think things out as carefully as you have.
> Like Vincent's idea
> with a space + backspace. Or space + backspace + clear-to-eol
I dunno, those hacks would likely just compound our misery. They sounded
a bit like trying to clean the lipstick off a pig. We're better off not
adding the lipstick in the first place, or even better yet not buying
the pig.
This bug report was last modified 51 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.