Bug 3993 - xterm terminal functions broken in rlogin session
Summary: xterm terminal functions broken in rlogin session
Status: CLOSED DUPLICATE of bug 2639
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86
Version: 6.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Preston Brown
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 1999-07-12 02:21 UTC by d_martin
Modified: 2008-05-01 15:37 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2000-01-18 20:24:52 UTC

Attachments (Terms of Use)

Description d_martin 1999-07-12 02:21:49 UTC
When I rlogin into a RH 6.0 box from my Solaris workstation,
any terminal function such as reverse or underline STAYS ON
until I do a reset, or some other terminal function begins.
Bold seems to work properly.

The problem only occurs when rloging into a RH 6.0 box (i.e.
RH 5.1 and 5.2 work fine) and only when the TERM variable is
set to xterm (i.e. changing to vt100 fixes the problem).  It
doesn't seem to be a problem when going from one 6.0 box to

I suspect the termcap entry is broken for xterm, but I don't
have time to muck with it.  Love to see this fixed --
setting TERM to vt100 all the time is a giant pain.

Comment 1 dmartin 1999-07-29 22:17:59 UTC
Anybody take a look at this yet?  Had a similar problem when coming
from an HP-UX machine.

Comment 2 Anonymous 1999-08-27 15:43:59 UTC
I have the same problem telneting into an RH6.0 box from an RH5.2 box.

emacs -nw doesn't work properly, as everything comes out reverse
video, and also some of the cursor positioning doesn't seem to be
working correctly.

Everything works right if I set TERM=nxterm, so it's probably the
termcap entry for xterm.

Comment 3 erik 1999-10-25 11:36:59 UTC
See the Xterm FAQ on
http://www.clark.net/pub/dickey/xterm/xterm.faq.html#xterm_hilite  The
Xterm developer thinks VT220 compatibility is more important for xterm
than compatibility with xterm itself, so he changed the escape codes.
Your Solaris and HPUX systems probably have an older xterm with the
old escape codes, your Linux machine probably has a new xterm with the
new termcap/info entries.  They don't match.

The best solution is probably to start all your xterms on the remote
machine with a term type that exists on both ends and uses the old
escape codes.  ncurses-4.2-18 on RH has the following termcap entries:

xterm-r5|xterm R5 version,
xterm-r6|xterm-old|xterm X11R6 version,
xterm-xf86-v32|xterm terminal emulator (XFree86 3.2 Window System),
xterm-xf86-v33|xterm terminal emulator (XFree86 3.3 Window System),
xterm-xf86-v333|xterm terminal emulator (XFree86 3.3.3 Window System),
xterm-xf86-v40|xterm terminal emulator (XFree86 4.0 Window System),
xterm-xfree86|xterm-new|xterm terminal emulator (XFree86 4.0 Window

And a few more

The default  xterm entry is almost the same as the xterm-xf86-v333
entry with some mouse handling differences.  One of these might exist
on both your Solaris and Linux machines and could be used with the
appropriate xterm resource or command line option.

IMHO changing the escape codes was a mistake and not changing the term
name was even worse.

Comment 4 erik 1999-10-26 09:20:59 UTC
I think this is the same as 2639 3785 3509

Comment 5 Preston Brown 2000-01-18 20:24:59 UTC
*** This bug has been marked as a duplicate of 2639 ***

Note You need to log in before you can comment on or make changes to this bug.