Bug 16823 - ssh vs rsh/rexec and keyboard mapping of <del> and <bs>
ssh vs rsh/rexec and keyboard mapping of <del> and <bs>
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
7.0
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Mike A. Harris
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-08-23 15:54 EDT by Mr. Berkley Shands
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-04-26 09:21:46 EDT
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 Mr. Berkley Shands 2000-08-23 15:54:31 EDT
Aug 23 14:41:26 russianblue xinetd[5097]: Bad line received from identity
server at 128.252.133.7: 1016

Aug 23 14:41:26 russianblue pam_rhosts_auth[5097]: allowed to
root@cts.wustl.edu as root
Aug 23 14:41:26 russianblue PAM_unix[5097]: (system-auth) session opened
for user root by (uid=0)
Aug 23 14:41:26 russianblue in.rshd[5098]: root@cts.wustl.edu as root:
cmd='exec /bin/csh -cf "setenv PATH
'${PATH}:/usr/bin/X11:/usr/local/bin/X11:/usr/X11/bin:/usr/X/bin:/pkg/X11/bin'; 
xauth remove mudpuddle.cs.wustl.edu:0.1 ; xauth merge -"'
Aug 23 14:41:26 russianblue automount[660]: attempting to mount entry
/pkg/X11


the common shell script "xrsh"
#!/bin/sh

# Some System V systems don't understand the #! construct.
#   If your system does understand it, put ": " at the beginning of the
line.
#
XRSH_VER='xrsh version 5.8-amc3' # AMC
XRSH_RCS='$Header: /usr/u/jjd/xrsh/RCS/xrsh.sh,v 1.12 1994/06/13 15:53:11
jjd Exp $'
XRSH_TIME='Time-stamp: <94/06/13 11:43:59 jjd>'
#
# Copyright 1991 by James J. Dempsey <jjd@bbn.com>

when used to access a RH 6.1 system correctly maps <del> and <bs> keys to
delete. The key would normally send ^[[3c or some such key codes.
under RH 6.2 and pinstripe, these codes are ignored and "~"  and <bell> are
printed.
I can "xterm -ls -n foo" once in and the keyboard mapping is still bad.
xmodmap and the other x utilities see a correct string for the keypress,
but
the system still ignores them. a ^H sent or a ^? sent is correct. it is
just
the multi-char escape sequence that gets munged.
using rsh/rexec/ssh2 does not show the problem.
Changing the $PATH does not fix it either.
using xmodmap to remap the keys does not fix it.
quite annoying (whatever breaks it is in xfree86*.rpm, since
I can apply theses rpm's to a 6.1 system and break it there).

not a really big problem, but as a system-admin with 100's of machines to
poke
at, it gets a bit tiring to remember ^H not <bs> :-)

berkley
Comment 1 Mike A. Harris 2001-04-25 16:29:53 EDT
I cannot replicate this.  Have you tried a newer release at all?  Is the bug
still present for you in red Hat Linux 6.2/7.0/7.1?

I know the pain you're having all too well from a long time ago though.  Not
with the same software, but with other broken setup...  That was in the "other"
OS though.  ;o)  It seems different people have had different but similar
experiences to yours, so I'd like to see if it is still present and fix it,
but I need a case that I can replicate here to get started first.
Comment 2 Mr. Berkley Shands 2001-04-26 09:17:54 EDT
This happens on 6.1, 6.2, 7.0, and 7.1. It happens comming from solaris, tru64,
and from secure-crt
off a WinDoze PC. It started with  3.3.6 of XFree86.

This does not happen to a version of Xfree86 4.0.x when compiled on Netbsd.
I have not tried a recompile and install on Linux.. I'll have to do that when I
want some more abuse :-)

I can supply the functional version of xrsh we use on our slowlaris boxes, via
mail
or anon-ftp let me know.

berkley
Comment 3 Mr. Berkley Shands 2001-04-26 09:21:41 EDT
xrsh source sent to mharris@redhat.com
Comment 4 Mike A. Harris 2001-05-20 19:07:53 EDT
I cannot reproduce this bug.

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