This is currently happening for any program run in an xterm that uses the tty in its basic "cooked" mode (subject to stty settings). The simplest such program is "cat".
It also happens with programs that might interactively ask for confirmation, such as "emerge -a", "cp -i", etc. You occasionally mistype the confirmation and try to use backspace, and encounter difficulties. These conditions are rare enough you might go weeks before realizing that backspace isn't working properly, which makes tracking down what changed more difficult... Similarly, if a no-echo password prompt fails, you are likely to conclude you lost track of what characters/backspaces you were typing, rather than conclude that backspace isn't actually working. In contrast, some common programs like "bash" and "vim" run the terminal in "raw" mode and (depending on lots of config details) often interpret both ^H and ^? in ways that hide that things are inconsistent elsewhere...
In gentoo, I think it was broken by a recent ncurses update changing the default "kbs" setting in the "xterm" terminfo database. This DB setting typically becomes the default "stty erase" setting:
Code: Select all
$ cat
abc^H^H^C
$ infocmp xterm | grep kbs
ka3=\EOy, kb2=\EOu, kbeg=\EOE, kbs=^?, kc1=\EOq, kc3=\EOs,
$ stty --all | grep erase
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
$
If I run infocmp in an intentionally-old unupdated chroot from 2020, I get "^H" instead of "^?", although I suspect this change is much more recent than 2020.
There seems to be a long-standing disagreement about whether the backspace key should mean "^H" or "^?". But I think it is definitely a
gentoo bug when the default setting in the ncurses DB entry and xterm program's default behavior are
not consistent with each other in a single install. I think gentoo should fix this inconsistency somehow, but I'm not sure how. There are several possibilities with different nuances... (Maybe someone should file a bug...)
Speculation: Perhaps the terminfo change was an attempt to resolve historically inconsistent "xterm" entries between different OS's? But my searches haven't found anything to indicate there is currently any such effort. In fact, ncurses has long seemed to punt on the issue, to the point where there is apparently a build-time configure option "--with-xterm-kbs" to switch it around (although gentoo's ncurses ebuilds do not seem to use it, and I haven't tried it myself). I was initially concerned that ssh-ing between machines could cause similar issues if the terminfo entries are different, although some testing suggests ssh copies the local "stty erase" setting over to the remote machine by default, which minimizes problems. (There could still be problems if some rare applications trust terminfo over "stty erase"...)
Background:
There are three conceptual settings that ideally should be consistent with each other:
- Which byte/character does xterm generate and feed to the pseudo-terminal when you press the backspace key?
- The terminfo "kbs" setting.
- The stty "erase" setting, which controls which byte/character a "cooked" mode terminal (in kernel) and/or most "raw" mode programs actually treat like a backspace.
Xterm and stty need to be consistent with each other. Most programs don't really care about the terminfo "kbs" setting directly, which allows ssh's copying of the stty setting to usually work even if "kbs" is inconsistent. But occasionally you could encounter programs where "kbs" does matter.
Settings and User Workarounds
- Use Control-Backspace instead of Backspace, as previously mentioned. (awkward)
- Use Control-LeftMouse to bring up a menu in xterm, and toggle the "Backarrow Key (BS/DEL)" option, which is called "backarrowKey" or DECBKM in the man page. (temporary)
- There are at least three X resource properties that xterm uses to control this. See "man xterm" page, especially the sections about "backarrowKeyIsErase", "backarrowKey", "ptyInitialErase", and "ttyMode".
- The interaction of xterm properties is complicated, but the most promising looks like "backarrowKeyIsErase". If set to true with others left as default, it looks like it makes the sent character and the initial/default stty erase setting match the current terminfo kbs DB entry, so everything is consistent, and will presumably still be consistent (toggled everywhere) even if a later update toggles the DB entry again. I'm not sure why it isn't the default. Maybe because there is apparently a DECBKM control sequence that a program can send to xterm to change the behavior of the backspace key, and "true" disables that sequence? But I don't understand why a program (or the program's user) would ever want to use such a sequence.
- TLDR maybe-best user workaround: Try putting "xterm*backarrowKeyIsErase: true" in your ~/.Xresources file (and/or maybe .Xdefaults). Not sure if you need to arrange to "xrdb -merge ~/.Xresources" yourself or not, and/or logout/login, but you definitely need to restart your xterms.
- "stty erase ^H" will also work for this specific case, but could break other cases, like if logged into the Linux console instead of an xterm, or anything else that uses ^?. This command could be placed in .profile or maybe .bashrc, possibly protected by checking various environment variables like "TERM", "SSH_*", "XTERM_*", etc...
- https://bugs.archlinux.org/task/74379 shows how to replace the "kbs" setting in the terminfo database, but of course that will be lost the next time you emerge ncurses...
- Maybe experiment with modifying the "--with-xterm-kbs" config option? But that requires customizing the ebuild...
EDIT 2024-05-31: I wrote up
https://bugs.gentoo.org/933302 to suggest that the OS defaults ought to be consistent with each other...