Re: Backspace echoed incorrectly with TERM=garbage
On Wed, Jun 17, 2020 at 09:30:25PM +, 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.
Re: Backspace echoed incorrectly with TERM=garbage
Also, of import in any terminal question is the content of your prompt (PS1 variable). See https://mywiki.wooledge.org/BashFAQ/053
Re: Bash-5.1-alpha available for download
On 6/17/20 12:28 PM, Andreas Schwab wrote: > mkdir -p -- > /home/abuild/rpmbuild/BUILDROOT/bash-5.0-lp151.10.125.1.x86_64/usr/share/man/man1 > ( cd ./po/ ; make > DESTDIR=/home/abuild/rpmbuild/BUILDROOT/bash-5.0-lp151.10.125.1.x86_64 > installdirs ) > make[1]: Entering directory '/home/abuild/rpmbuild/BUILD/bash-5.1-alpha/po' > /bin/sh @MKINSTALLDIRS@ > /home/abuild/rpmbuild/BUILDROOT/bash-5.0-lp151.10.125.1.x86_64/usr/share > /bin/sh: @MKINSTALLDIRS@: No such file or directory Thanks for the report. It looks like AM_MKINSTALLDIRS has disappeared with the update I did for the m4 modules. I'll have to add a definition back in that one Makefile manually. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Backspace echoed incorrectly with TERM=garbage
On 6/17/20 5:30 PM, bry...@giraffe-data.com wrote: > Bash Version: 5.0 > Patch Level: 3 > Release Status: release > > Description: > > 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. Sorry, I can't reproduce this. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Backspace echoed incorrectly with TERM=garbage
> I imagine that depends on your terminal and your stty settings. On MacOS with > Bash 5 in Terminal.app what you describe doesn't happen for me. What terminal > are you using? What is the output of stty -a with respect to erase? What do > you get in that setup when you press Ctrl-V then Backspace? Thanks for trying to reproduce it. I see this with an X.org xterm under Linux and a Linux virtual console, both through SSH (Openssh), and Putty in Windows, via Putty's SSH. To simplify things, I set my erase key to "q" (stty erase q). ctl-V q confirms terminal sends q when I type it. Behavior is the same - q functions as backspace, gets echoed as space. In Bash 4, it gets echoed as backspace. I used 'script' to verify that the terminal is receiving an ASCII space (0x20) character. -- Bryan Henderson San Jose, California
Re: Backspace echoed incorrectly with TERM=garbage
On Thu, Jun 18, 2020 at 08:53:57PM +, Bryan Henderson wrote: > I see this with an X.org xterm under Linux and a Linux virtual console, both > through SSH (Openssh), and Putty in Windows, via Putty's SSH. > > To simplify things, I set my erase key to "q" (stty erase q). ctl-V q > confirms terminal sends q when I type it. Behavior is the same - q functions > as backspace, gets echoed as space. In Bash 4, it gets echoed as backspace. I cannot reproduce this in xterm under Debian 10, at least not with the packages and settings I am using. I don't recall ever hearing of anyone complaining about this before, so it might be something unique to your setup, or your build of bash. It might be worth pointing out, "echoed as backspace" isn't really a meaningful phrase on its own. When you press Backspace to erase a character, what normally happens is that three characters are sent to the terminal: backspace, space, and backspace. The first backspace moves the cursor to the left, the space overwrites the character on the screen with a space (and moves the cursor right), and the second backspace moves the cursor left again. This behavior is controlled by the "echoe" setting in stty(1). Is it possible that your terminal is receiving BS-space-BS and for whatever reason, is ignoring/discarding the two BS characters, and therefore not moving the cursor where it's supposed to be? That's the best guess I have at the moment.
Re: Backspace echoed incorrectly with TERM=garbage
> When you press Backspace to erase a character, what normally happens is that > three characters are sent to the terminal: backspace, space, and backspace. > ... > Is it possible that your terminal is receiving BS-space-BS and for whatever > reason, is ignoring/discarding the two BS characters, and therefore not > moving the cursor where it's supposed to be? That's the best guess I > have at the moment. Thanks for that explanation. This seems really likely, as it explains the treatment of the other line editing commands. Ctl-a results in no cursor motion at all, while Ctl-u results in a number of spaces equal to the cursor position being printed. But both edit the line correctly. I assumed from the beginning that the problem was somewhere in the pipeline other than inside Bash, but I can't get around the fact that the problem consistently occurs with Bash 5 and not Bash 4. The Bash 5 is both the one that comes with Debian 10 and the alpha version I compiled myself yesterday. The Bash 4 is what came with Debian 9 - I run it side by side on the Debian 10 system with the Debian 10 Bash and one exhibits the problem and the other does not. Well, it turns out the 'script' program is not a reliable way to see what is being sent to the terminal. It does not report any control characters received even when the cursor moves correctly. Any ideas on how I could see the raw character stream sent to a terminal? Say, I wonder what intelligence Bash uses to decide how to move the cursor to the left in the absence of terminfo. -- Bryan Henderson San Jose, California
Re: Backspace echoed incorrectly with TERM=garbage
On Thu, Jun 18, 2020, 6:03 PM Bryan Henderson wrote: > ... Any ideas on how I could see > the raw character stream sent to a terminal? > > Try the xev program. It will show X events and may reveal the keypresses you're interested in. >
Re: Backspace echoed incorrectly with TERM=garbage
> Try the xev program. It will show X events and may reveal the keypresses
> you're interested in.
Thanks. The mystery here is on the other side - things received by the
terminal, not keys pressed.
But I thought of 'strace'. I attached that to the Bash process and
clearly saw it sending only space characters, no backspaces:
pselect6(1, [0], NULL, NULL, NULL, {[], 8}) = 1 (in [0])
read(0, "q", 1) = 1
write(2, " ", 1)= 1
pselect6(1, [0], NULL, NULL, NULL, {[], 8}) = 1 (in [0])
read(0, "q", 1) = 1
write(2, " ", 1)= 1
Compared to the better Bash 4 behavior:
read(0, "q", 1) = 1
write(2, "\10 \10", 3) = 3
read(0, "q", 1) = 1
write(2, "\10 \10", 3) = 3
(N.B. "q" is the "erase" character for this experiment).
(N.B. "\10" is ASCII backspace (ctl-H) in octal)
I see what is probably the crucial difference between my working Bash 4 and
my nonworking Bash 5: Different Ncurses shared libraries. The former uses
libncurses.so.5 _and_ libtinfo.so.5, while the latter uses only
libtinfo.so.6.
Still doesn't explain why this is a problem only for me, though.
--
Bryan Henderson San Jose, California
Re: Backspace echoed incorrectly with TERM=garbage
>But I thought of 'strace'. I attached that to the Bash process and
>clearly saw it sending only space characters, no backspaces:
>
>pselect6(1, [0], NULL, NULL, NULL, {[], 8}) = 1 (in [0])
>read(0, "q", 1) = 1
>write(2, " ", 1)= 1
I can reproduce this behavior, using bash 4.4(23) and readline 7.0(5):
read(0, "\177", 1) = 1
write(2, " ", 1)= 1
I also have ncurses-6.2, with readline linking directly to libtinfo.
If I link readline against ncurses-5.9 (forcing -lncurses), the problem
goes away:
read(0, "\177", 1) = 1
write(2, "\10 \10", 3) = 3
So the problem may be either in ncurses itself or in readline's
interaction with ncurses/libtinfo.
--Andrew Church
http://achurch.org/
