I am logging into an Arch Linux install running on an ARM dev board via USB serial connection. Installation went smoothly, and everything seems fine. However, my console is behaving strangely; it doesn't appear to be clearing the line in response to various commands. Examples are easier to understand (although hard to depict):

$ mkdir test
*Press delete*
$ mkdir test*space*

I know that delete is working, because executing the above command makes a tes directory. It just doesn't seem to have the correct behavior on the display of the command. I have checked 'stty -a' and erase is correct (^?). It's more evident using bash's history:

$ mkdir test
$ cd test
*Up Arrow* *Up Arrow*
$ cd testmkdir test

I have tried logging in to the board via screen and a separate GUI program, and both demonstrate the same behavior. I'm sure this is a simple configuration mistake, but I can't seem to find any other questions where this is happening. Any ideas?

1 Answer 1


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

  • This is useful information, thanks. As to fixing the mismatch, I've tried changing the term variable to a number of alternatives (xterm, vt100, linux) and none seem to work. When I try to check the terminfo db, infocmp errs with infocmp: 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, 2018 at 20:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .