Re: Backspace echoed incorrectly with TERM=garbage

[Greg Wooledge]

On Wed, Jun 17, 2020 at 09:30:25PM +0000, bryanh@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.