GNU bug report logs - #15444
One character can be lost if colors are enabled

Previous Next

Full log

View this message in rfc822 format

From: Paul Jackson <pj <at> usa.net>
To: 15444 <at> debbugs.gnu.org
Subject: bug#15444: (no subject)
Date: Wed, 13 Jul 2016 17:37:18 -0500

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.