On Tue, Dec 18, 2007 at 06:40:13PM +0100, Loïc Minier wrote:
> Package: xterm
> Version: 229-1
> Severity: normal
>
> Hi,
>
> Got a surprizing issue with grep colored output today; it seems that if
> coloring starts around the end of the line, the last char is chopped.
>
> e.g.:
> echo " 1234" | grep --color=auto '[1-9]'
> (80 spaces and 1234)
>
> displays ... nothing.
Surprising things happen (with VT100 emulators) when you send control
characters at the right-margin. I documented one of those some time
ago in vttest:
20040804
add a demo of some of the VT100 autowrap behavior to menu 1.
(it demonstrates that gnome-terminal doesn't do wrapping the way a VT100
would).
My more-detailed note in vttest says
* main.c:
add some tests for DECAWM to the menu-1 series. This exercises some of the
boundaries observed and compared with dxterm and DEC's manuals: wrapping
only occurs when a graphic character is written to the right margin and
followed immediately by another graphic character. Writing a backspace
or other control causes it to lose interest in wrapping.
> If I add more spaces or remove some, I see most of 1234 in red,
> but it's sometimes chopped at the end of the line.
>
> gnome-terminal works fine with the same test cases.
gnome-terminal works differently, but some analysis is needed to say
whether it (or xterm) "works fine". For a quick check, I notice that
it's displaying the first "1" one column too early (it shouldn't appear
on column 80, as I see it doing on my screen ;-). unsurprisingly, konsole
has the same defect.
rxvt does a little better, showing the "234" on the next line, and
nothing on the first line. pterm acts like rxvt (however, pterm's
wrapping behavior is known to differ from xterm's ;-).
grep is sending lots of interesting control characters at the right-margin.
_After_ it passes the 80-spaces, it sends this (in readable form):
\E[01;31m
\E[K1
\E[m
\E[K
\E[01;31m
\E[K2
\E[m
\E[K
\E[01;31m
\E[K3
\E[m
\E[K
\E[01;31m
\E[K4
\E[m
\E[K\r
xterm (even the 10-year-old X11R6 xterm) doesn't wrap. That's because
it's seeing this sequence of operations:
\E[01;31m
set SGR for color - well that may apply to the next text.
\E[K1
erase from the current position (we're "after" column 80),
and then write a "1" (this is saved for the moment because
we won't try writing the "1" until the _next_ graphic character
forces the wrapping to proceed).
\E[m
unset the SGR (no matter - we haven't used it)
\E[K
erase from the current position. Hmm: we haven't moved the cursor,
so this only succeeds in erasing the pending character which was
saved to possibly display on the next line.
repeat indefinitely - no visible output.
On the positive side, gnome-terminal's had this bug for quite a while.
It's a bug in gnome-terminal, since its documentation claims:
Run any application that is designed to run on VT102, VT220,
and xterm terminals
If its wrapping behavior were documented, one could conceivably call it
a feature. But it's not matching the VT100 wrapping behavior.
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
Attachment:
pgpKWfCflR4bh.pgp
Description: PGP signature