Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 170411 - ssh root sessions started under xterm have stty erase not set to ^H (probably unrelated to KDE)
Summary: ssh root sessions started under xterm have stty erase not set to ^H (probably...
Status: RESOLVED TEST-REQUEST
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo X packagers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-03-11 13:58 UTC by CPUShare
Modified: 2009-05-06 09:18 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description CPUShare 2007-03-11 13:58:04 UTC
I'm running under KDE and if I use konsole everything is fine and this problem doesn't exist (so I suspect this is an xterm bug).

If I "ssh root@somehost" under xterm, the remote shell doesn't have stty erase set to ^H. So if I run 'cat' and I press backspace I see ^H instead of the proper behavior. running stty erase ^H manually after login fixes it. If I don't log as root, like if I run "ssh user@somehost" everything is fine. This is reproducible on x86 and amd64, and the remote host doesn't need to be a gentoo system (so the xterm client side again seems suspect, ssh is less suspect because with konsole the problem doesn't happen).

user@host1 ~ $ ssh root@host2
Last login: Sun Mar 11 14:16:11 2007 from host1.domain
host2 ~ # stty
speed 38400 baud; line = 0;
-brkint -imaxbel
host2 ~ # logout
Connection to host2 closed.
user@host1 ~ $ ssh user@host2
Last login: Sun Mar 11 14:24:01 2007 from host1.domain
user@host2 ~ $ stty
speed 38400 baud; line = 0;
erase = ^H;
-brkint -imaxbel
user@host2 ~ $ 

Can anybody else reproduce this with xterm or am I the only one?

Reproducible: Always

Steps to Reproduce:
1.start xterm
2.ssh root@somehost
3.run cat and then backspace

Actual Results:  
^H is printed instead of erase being processed.

Expected Results:  
backspace should be processed instead of seeing ^H on the screen
Comment 1 CPUShare 2007-04-08 15:04:23 UTC
I found a solution, if it's a workaround or a fix it's up to you to decide.

XTerm.backarrowKeyIsErase: true
XTerm.ptyInitialErase: true

That avoids xterm to set erase to ^H in the first place, and so everything is ok when logging remotely as root the erase returns to ^?.

If it's a fix perhaps it's good idea to add it to the xterm app defaults so it'll actually work without having to tweak things by hand (I tried unmasking the latest ~amd64 xterm and that didn't fix it either).

thanks.
Comment 2 Wulf Krueger (RETIRED) gentoo-dev 2007-05-01 18:51:12 UTC
Yes, I can reproduce this using x11-terms/xterm-225. Not our bug, though. 
Reassigning to X11.
Comment 3 CPUShare 2007-05-01 20:50:03 UTC
I'm glad it wasn't a screwup on my side.

My current functional settings (deviating from the default) are:

XTerm.backarrowKeyIsErase: true
XTerm.ptyInitialErase: true
XTerm.vt100.metaSendsEscape: true

The metaSendsEscape:true is needed so that the ALT key works as expected (that's unrelated to the backspace problem reported previously).

They probably should become the new defaults.
Comment 4 Donnie Berkholz (RETIRED) gentoo-dev 2008-01-11 08:08:08 UTC
I just bumped to xterm 231, have a look-see.
Comment 5 Donnie Berkholz (RETIRED) gentoo-dev 2008-03-12 23:22:23 UTC
How's it work in 234? I just added it.
Comment 6 Samuli Suominen (RETIRED) gentoo-dev 2009-05-06 09:18:48 UTC
(In reply to comment #5)
> How's it work in 234? I just added it.
> 

And I've just added #243 and there has been no feedback here, closing as TEST-REQ.