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.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.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> 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
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.
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
xrsh source sent to mharris
I cannot reproduce this bug.