Re: the telnet/rlogin problem
> Hi guys,
> While the proposed set of solutions generally works fine (letting xterm
> use DEL and \e[3~, and leaving BS for apps), the telnet problem (remote
> machines are likely to have kbs=^H, kdch1=\177 terminfo entries) is a
> serious one. The expect script works fine locally, and could maybe be
> made a bit more elaborate with a list of "broken hosts", letting a
> script choose whether to use the expect-keyswitch or not. However, how
> can we gracefully handle telnet requests? People telnetting from a
> machine with a "broken" (to our definition...) terminfo will find that
> [<---] deletes under the cursor and [Delete] will not work. Any
That's not quite right, [<---] will be generating ASCII BS, which we take to
mean emacs help, and perhaps (in bash for example) delete-left.
[Delete] will be generating ASCII DEL which will do delete-left, so they don't
get to do delete-under-cursor, and [<---] will often insert ^H.
> It all comes down to having fixed something in a broken
> environment I guess. The only thing I can think of is letting people
> choose a terminal type when they log in, in this case I guess there
> should be an alternative entry, xterm.old or something (or something
> they're a bit more likely to choose...). Any ideas? I think it would be
> a shame if we got stuck on this.
They just need to set stty in their .profile
They can make this dependent upon $REMOTEHOST if necessary (i.e. if they
only sometimes come in from a broken host).
If that does not work, it is a bug in the application (because it should take
heed of stty), which needs to be reported.
While such bugs exist, they could always set TERM to xterm-bs (or whatever)
at the same time as setting stty erase ^h.
possible /etc/profile snippet:
# deal with connections from terminals who's [<---] key generates ASCII BS
if grep -q "^$REMOTEHOST\$" /etc/broken-backspace-hosts ; then
stty erase '^h'
# handle buggy apps.
[ "$TERM" = xterm ] && TERM=xterm-bs
To UNSUBSCRIBE, email to firstname.lastname@example.org
with a subject of "unsubscribe". Trouble? Contact email@example.com