Your TERM
environment variable seen by the GNU Readline library in the Bourne Again shell must denote the correct record in the terminfo database that matches what the terminal at the end of your serial connection actually is.
If you have a switchable terminal type in a terminal emulator at the end of your serial connection, the TERM
variable must switch to match whatever the current setting is.
Traditionally a local real terminal remains physically connected to the same serial line, and the system administrator makes a one-off configuration change so that the getty
program is invoked with the right terminal type. In these days of PCs running emulator programs connected to their serial devices, pretending to be real terminals, one must either keep the emulator configured the same or reconfigure the host system whenever the emulator program is changed.
Currently there is a mismatch, and the control sequence(s) that the GNU Readline library emits to move the cursor backwards, that it has read from the TERM
-denoted record in the terminfo database, do not match the control sequence(s) that your terminal or terminal emulator actually recognizes to move the cursor backwards.
(Deleting to the left when at the end of the line being input is enacted by Readline moving the cursor backwards, printing a space, and moving the cursor backwards again. Observe that Readline always uses the cub
capability, never the cub1
capability. No terminal uses the ␈
character in its cub
capability. So how your terminal responds to ␈
is a red herring. It is how it responds to the actual control sequence in the cub
capability that is important.)
The line discipline special characters listed by stty
are a red herring for two reasons. They are input processing unrelated to the output control sequences used by the GNU Readline library. And GNU Readline puts the terminal into non-canonical input mode anyway when editing a command line is actually happening.
Further reading
infocmp
errs withinfocmp: couldn't open terminfo file /usr/share/terminfo/x/xterm.
To me, that implies that the Readline library isn't reading the TERM-denoted record. I've checked the file and it exists with read permissions. Any other ideas? – Nick Sep 21 '18 at 20:44