Problem with terminfo's sgr
Johann 'Myrkraverk' Oskarsson
I've been playing with mrxvt, and tried setting TERM=xterm-256color
which works, most of the time.
However on one host, it doesn't. I'm using the same terminfo entry on
all hosts, so this is a bit puzzling to me. I managed to track the
problem to the sgr entry in the terminfo. This is the one that
doesn't work:
sgr=\E[0%?%p6%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;
%?%p4%t;5%;%?%p7%t;8%;m%?%p9%t\E(0%e\E(B%;
And this is the one I'm currently using (from my xterm entry):
sgr=\E[0%?%p1%p6%|%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;
7%;%?%p4%t;5%;%?%p7%t;8%;m%?%p9%t\016%e\017%;
(Of course without the linefeeds)
So my question is: how do I find out what's causing trouble? I'm
pretty sure it's somewhere in mrxvt, but I haven't been able to locate
it easily ;/
I would help if I understood the entry and could play with it a bit
manually.
Also, why only *this* host, why not all the others too?
Johann
Thomas Dickey
> Hi,
> I've been playing with mrxvt, and tried setting TERM=xterm-256color
> which works, most of the time.
> However on one host, it doesn't. I'm using the same terminfo entry on
> all hosts, so this is a bit puzzling to me. I managed to track the
> problem to the sgr entry in the terminfo. This is the one that
> doesn't work:
> sgr=\E[0%?%p6%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;
> %?%p4%t;5%;%?%p7%t;8%;m%?%p9%t\E(0%e\E(B%;
"doesn't work" for what applications?
There's a bug that I fixed last year for termcap support of applications
such as screen which are confused by the corresponding sgr0 string when
it modifies the alternate character set mode.
See http://invisible-island.net/ncurses/NEWS.gz
20040710
+ modify logic in tgetent() which adjusts the termcap "me" string
to work with ISO-2022 string used in xterm-new (cf: 20010908).
(curses applications are unaffected, but it's noticable in screen).
> Also, why only *this* host, why not all the others too?
different versions, different bugs
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
Johann 'Myrkraverk' Oskarsson
> Johann 'Myrkraverk' Oskarsson <myrkr...@users.sourceforget.net> wrote:
> > I've been playing with mrxvt, and tried setting TERM=xterm-256color
> > which works, most of the time.
> > However on one host, it doesn't. I'm using the same terminfo entry on
> > all hosts, so this is a bit puzzling to me. I managed to track the
> > problem to the sgr entry in the terminfo. This is the one that
> > doesn't work:
> > sgr=\E[0%?%p6%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;
> > %?%p4%t;5%;%?%p7%t;8%;m%?%p9%t\E(0%e\E(B%;
> "doesn't work" for what applications?
Zsh, and gnu emacs are the only ones I found affected. And only on
mrxvt, my konsole, xterm and gnome-terminal seemed to work ok
(however, none of them are built with 256 color support, and I like
the multi-tabs).
> There's a bug that I fixed last year for termcap support of
> applications such as screen which are confused by the corresponding
> sgr0 string when it modifies the alternate character set mode.
>
> See http://invisible-island.net/ncurses/NEWS.gz
>
> 20040710
> + modify logic in tgetent() which adjusts the termcap "me" string
> to work with ISO-2022 string used in xterm-new (cf: 20010908).
>
> (curses applications are unaffected, but it's noticable in screen).
>
> > Also, why only *this* host, why not all the others too?
>
> different versions, different bugs
Obviously ;)
I'm pretty sure this is one of them doubly-edged bugs, but do you mind
telling me what the sgr means so I can try to track down the mrxvt
part of it? I've tried reading the terminfo man page, but I relly get
neither heads nor tails of it ;/
I get it from (what was) Fedora Core 1 host, but on my (slowly
digressing) Fedora Core 3 it's fine, so I don't think I'm going to try
to track down the other end.
Johann
Johann 'Myrkraverk' Oskarsson
> I'm pretty sure this is one of them doubly-edged bugs, but do you mind
> telling me what the sgr means so I can try to track down the mrxvt
> part of it? I've tried reading the terminfo man page, but I relly get
> neither heads nor tails of it ;/
Nevermind, I got it to the following syntax:
print "\e[0"
if (bold) ";1" ;
if (underline) ";4" ;
if (standout | reverse) ";7" ;
if (blink) ";5" ;
if (invisible) ";8" ;
"m"
if (altcharset) "\e(0" else "\e(B" ;
Johann
Thomas Dickey
yes - something like that. The termcap-specific problem I mentioned is
in the last part (both the sgr and sgr0 string in terminfo set/reset the
alternate character set; termcap assumes sgr0 does nothing, so ncurses tries
to filter it out - but the filtering was only working for single characters
such as ^N).
The infocmp "-f" option chops up the string so it's more readable.
I usually do something like "infocmp -1f" to read those strings.
To see what version of ncurses you have on either machine, the -V option
of tic and infocmp gives that information.
Thomas Dickey
> Zsh, and gnu emacs are the only ones I found affected. And only on
> mrxvt, my konsole, xterm and gnome-terminal seemed to work ok
> (however, none of them are built with 256 color support, and I like
> the multi-tabs).
That's odd - that mrxvt differs from the other emulators.
I have noticed that rxvt/etc don't implement some erases (with color)
consistently with the other operations, but would not think that zsh
is exercising that aspect.
zsh and emacs probably are using the termcap interface.
> I'm pretty sure this is one of them doubly-edged bugs, but do you mind
> telling me what the sgr means so I can try to track down the mrxvt
> part of it? I've tried reading the terminfo man page, but I relly get
> neither heads nor tails of it ;/
I guess (from your followup) that you've gotten this far.
sgr stands for "set graphic rendition" (jargon).
That means it is setting (or resetting) the video attributes such as
bold, underlining. Alternate character set (line-drawing) is part of
that.
> I get it from (what was) Fedora Core 1 host, but on my (slowly
> digressing) Fedora Core 3 it's fine, so I don't think I'm going to try
> to track down the other end.
I seem to recall that Fedora Core 3 uses a snapshot of ncurses late
enough to have the bug-fix that I mentioned.
Johann 'Myrkraverk' Oskarsson
> Johann 'Myrkraverk' Oskarsson <myrkr...@users.sourceforget.net> wrote:
>
> > Zsh, and gnu emacs are the only ones I found affected. And only on
> > mrxvt, my konsole, xterm and gnome-terminal seemed to work ok
> > (however, none of them are built with 256 color support, and I like
> > the multi-tabs).
>
> That's odd - that mrxvt differs from the other emulators.
Update: there's a problem with gnome-terminal (FC3 version) too.
Actually, what I see in in mrxvt is [27m in front of my prompt in zsh,
and lot's of [39;49m in emacs. Mrxvt doesn't seem to have a good
framework to debug its state machine, but I believe I'm getting
something one the lines of \E(\E[27m. I have confirmed it tries to
set it's codepage* to 27 (ESC) while on other hosts it's 66 (B).
* Is my DOS heritage showing?
I guess I'll need to insert a kludge to workaround this; I guess I
should since one never knows when a host will have buggy curses, does
one?
> I have noticed that rxvt/etc don't implement some erases (with color)
> consistently with the other operations, but would not think that zsh
> is exercising that aspect.
I don't think that's related, but if you bother to tell me what it
should be doing, I can try to make sure it's right in mrxvt ;)
> zsh and emacs probably are using the termcap interface.
Probably. However, while trying to track this down, I compiled
ncurses 5.4 and tried setting the LD_LIBRARY_PATH to the new one, but
that didn't seem to change anything. (At the time I wasn't sure there
was a problem with ncurses, a host which has 4.0 is fine). Do I need
to install it to see the effects of the bugfix?
Johann
Thomas Dickey
> Actually, what I see in in mrxvt is [27m in front of my prompt in zsh,
> and lot's of [39;49m in emacs. Mrxvt doesn't seem to have a good
> framework to debug its state machine, but I believe I'm getting
> something one the lines of \E(\E[27m. I have confirmed it tries to
That's the sort of thing that I was talking about. The symptom that I
First noticed that that the first character of a shell command was not
echoing - but there are certainly difference visual effects that can
happen from this.
> set it's codepage* to 27 (ESC) while on other hosts it's 66 (B).
> * Is my DOS heritage showing?
> I guess I'll need to insert a kludge to workaround this; I guess I
> should since one never knows when a host will have buggy curses, does
> one?
The easy workaround is to use a terminfo with ^N/^O rather than \E(B, etc.
The original reason for using the latter is to make the terminfo's work
with luit (and some other program that doesn't come to mind at this instant).
>> I have noticed that rxvt/etc don't implement some erases (with color)
>> consistently with the other operations, but would not think that zsh
>> is exercising that aspect.
> I don't think that's related, but if you bother to tell me what it
> should be doing, I can try to make sure it's right in mrxvt ;)
I seem to recall that the insert- and delete-character operations do not
cause the newly-blanked cell to be filled with the current background
color, which is inconsistent with the various erasure operations.
>> zsh and emacs probably are using the termcap interface.
> Probably. However, while trying to track this down, I compiled
> ncurses 5.4 and tried setting the LD_LIBRARY_PATH to the new one, but
> that didn't seem to change anything. (At the time I wasn't sure there
> was a problem with ncurses, a host which has 4.0 is fine). Do I need
> to install it to see the effects of the bugfix?
This particular bug exists between 20010908 and 20040710 - ncurses 4.0
is older than that (I assume you're talking about ncurses 4.2 which is
from 1998).
You'd need ncurses 5.4 + rollup patch. There are several rollup patches
here:
ftp://invisible-island.net/ncurses/5.4
e.g.,
patch-5.4-20040711.sh
patch-5.4-20041211.sh
patch-5.4-20050319.sh