On Wed, Jun 17, 2020 at 09:30:25PM +0000, bry...@giraffe-data.com wrote: > With TERM environment variable set to an undefined terminal type, Bash > echoes a backspace as a space; I expect it to echo as a backspace (ctl-h). > It edits the line properly; it just isn't displayed correctly. > > Other line editing functions have the same problem. > > Setting TERM from the Bash prompt (to anything) puts things back to normal.
As Dennis says, there's a lot more involved here than just the TERM variable. The byte that's sent when you press the Backspace key is defined by the terminal's hardware (if it's a physical terminal) or by its configuration settings (if it's a terminal emulator). Most terminals send either the BS byte (0x08) or the DEL byte (0x7f). On the host side, the system's terminal driver has a configuration setting for what it *thinks* the terminal's Backspace byte is going to be. This is controlled at the shell level with the stty(1) command's "erase" attribute. So, either: stty erase ^h # or stty erase ^? Applications that rely on "canonical mode" terminal editing will allow the terminal driver to handle Backspace according to whatever is in the driver's configuration. If this matches the terminal's output byte, all is well. If it doesn't, then Backspace won't work. Bash (readline) does not rely strictly on canonical mode. In bash, both BS and DEL are treated as Backspace. So, it's easy to think that everything is fine if you only test Backspace within bash. But programs that you run *from* bash won't necessarily be OK. Next, bash (readline) has a few different ways it can handle the display of characters on the terminal during interactive editing. It chooses a strategy based on the TERM variable. If TERM is set to something sensible, like xterm or vt220 or linux, bash will make use of the terminal's ability to position the cursor and erase partial lines. However, if TERM is set to something unrecognizable, bash will have to fall back to more primitive methods. The most obvious example is when you type a command that goes beyond the right edge of the terminal. Normally, bash will scroll the terminal up one line (if necessary), and continue displaying input on the next line, allowing you to see both lines at the same time. But in what I'll call "dumb terminal mode", this doesn't happen. Instead, the current line is fully erased and redrawn, displaying only the ending part of the input. You won't be able to see the whole input line all at once. (This is also ksh behavior.) The short answer is "don't set TERM incorrectly". The longer answer is, if you think you've discovered a bug in readline's terminal handling, be ultra precise in how you report it. First of all, make sure what you're seeing is not the expected behavior for a reduced-capability environment. If you still think it's wrong, give *exact* instructions for how to reproduce it. Exactly what operating system, terminal or terminal emulator, terminal configuration if applicable, stty -a output, content of TERM, possibly the OS's terminfo or termcap entry for that TERM variable, the *exact sequence of keys you press* to produce the behavior, the exact screen output you see, and the screen output you expected to see.
