Bug 3993 - xterm terminal functions broken in rlogin session
xterm terminal functions broken in rlogin session
Status: CLOSED DUPLICATE of bug 2639
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
6.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Preston Brown
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-07-11 22:21 EDT by d_martin
Modified: 2008-05-01 11:37 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-01-18 15:24:52 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description d_martin 1999-07-11 22:21:49 EDT
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
another.

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 18:17:59 EDT
Anybody take a look at this yet?  Had a similar problem when coming
from an HP-UX machine.
Comment 2 Anonymous 1999-08-27 11:43:59 EDT
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 07:36:59 EDT
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
System),

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 05:20:59 EDT
I think this is the same as 2639 3785 3509
Comment 5 Preston Brown 2000-01-18 15:24:59 EST
*** 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.