With default configurations, current versions of ncurses (terminfo kbs setting for "TERM=xterm") and xterm itself have incompatible handling of the backspace key. By default, the xtern sends ASCII code 8 (^H) when you press backspace, while the terminfo entry (and the intial default "stty erase" setting) default to 127 (^?). As a result, backspace essentially doesn't work for any program running the terminal in kernal-handled "cooked" mode ("mail", "cat", "cp -i ...", "emerge -a ...", various programs that ask for passwords or passpharses, etc). These days such programs are rare enough that it can take a while to notice backspace is broken... Some command invocations and output using default settings (the ^H's in the second line are from pressing the backspace key): ---- $ 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; $ emerge -pv ncurses xterm [snip] [ebuild R ] sys-libs/ncurses-6.4_p20240414:0/6::gentoo USE="cxx doc (split-usr) stack-realign (tinfo) -ada -debug -gpm -minimal -profile -static-libs -test -trace -verify-sig" ABI_X86="32 (64) (-x32)" 0 KiB [ebuild R ] x11-terms/xterm-390::gentoo USE="openpty truetype unicode -Xaw3d -sixel -toolbar -verify-sig -xinerama" 0 KiB [snip] ---- I think this broke when a semi-recent update to ncurses changed the default terminfo setting. I confirmed this when I used "infocmp xterm" in an intentionally-old unupdated gentoo chroot from 2020, where kbs was set to ^H. (I think it changed much more recently than that, but haven't tried to track down exactly when.) The new setting may be consistent with decisions apparently made by Debian back in the 90's: https://lists.gnu.org/archive/html/bug-ncurses/2023-01/msg00008.html and https://www.debian.org/doc/debian-policy/ch-opersys.html#keyboard-configuration I also wrote a moderately detailed analysis of this in https://forums.gentoo.org/viewtopic-t-1168744.html on May 24, including some possible end-user workarounds. ---- As my forum post points out, there are a lot of adjustable settings that affects this, and corresponding ways users can work around inconsistent defaults. I don't really care what the defaults actually are, but I think it is reasonable to expect that *they should be self-consistent within a single OS install.* Here is my brainstorm about some of the possible ways to make them consistent, and some downsides of each: 1. Maybe revert the ncurses terminfo kbs for xterm back to "^H"? I think there is a "configure" option that can do that... (Although this would apparently be inconsistent with the Linux console, Debian, and maybe other things. Depending on what workaround(s) users may have already applied, it could also break things *again*...) 2. Maybe set the default xterm X resource "backarrowKeyIsErase" to true instead of false? If I read the manpage correctly, this (along with other unmodified defaults) will tell xterm to make itself fully consistent with whatever is in the terminfo "xterm" kbs setting by default, even if ncurses updates decide to toggle its installed kbs value occasionally. (However, if I understand the man page correctly, this might also disable a special control sequence that a program can send to xterm to toggle the behavior of the backspace key. Does any program actually use that control sequence? Also, if we change the installed default, the xterm man page should probably reflect that...) 3. Maybe just make sure we hard code set the installed "backarrowKey" and/or "ptyIntialErase" to ultimately result in consistency with what we (now intentionally) set as the ncurses/terminfo default kbs, without actually consulting terminfo at runtime... (Read the man page more carefully; maybe only one of these is needed?) 4. Maybe tie all the relevant xterm (3) and ncurses/terminfo (1) default settings to a new global USE flag (maybe also used by other packages?). (This seems like overkill, but if people can't agree on one convention, maybe it would be worth it...) Reproducible: Always
