| View previous topic :: View next topic |
| Author |
Message |
jagdpanther
l33t
Joined: 22 Nov 2003
Posts: 736
|
 Posted: Thu May 02, 2024 2:30 am Post subject: CLI mail app backspace broken |
 |
|
Inside a terminal window (xterm) backspace normally works as expected. However, when using 'mail' CLI program (from mailx package) both when typing the "Subject:" and the body when I press backspace I receive what looks like a ^H (shift-6 followed by "H") instead of erasing a character. Any idea where I should start looking to fix this? (Also if someone knows some other key combination to simulate a backspace, please let me know.)
For example on each line of the following I made an error (extra character) and pressed backspace. Only on the first line, before 'mail' runs, did backspace work as expected:
| Code: | $ mail testuser@localhost
Subject: test messagee^H
This is a test linee^H
.
Cc:
$
|
|
|
| Back to top |
|
 |
myga
Tux's lil' helper
Joined: 12 Jun 2023
Posts: 110
|
| Posted: Thu May 02, 2024 3:49 am Post subject: |
|
|
Just tested it on Mint from Windows Terminal using SSH and it works fine on BASH, SH, & ZSH. I'm suspecting the terminal emulator you are using is the issue.
_________________
[Never break the law to save people. Nope, there aint no heroes here. Unless you are 'Satoshi Nakamoto', that's a true anonymous.] |
|
| Back to top |
|
|
jagdpanther
l33t
Joined: 22 Nov 2003
Posts: 736
|
| Posted: Thu May 02, 2024 4:15 am Post subject: |
|
|
| Quote: | | I'm suspecting the terminal emulator you are using is the issue. |
Ok. That is correct. I just dropped down to a console (<ctrl><alt>F2) and there backspace in the mail CLI app works.
So what is wrong with xterm? |
|
| Back to top |
|
|
Banana
Veteran
Joined: 21 May 2004
Posts: 1416
Location: Germany
|
|
| Back to top |
|
|
jagdpanther
l33t
Joined: 22 Nov 2003
Posts: 736
|
| Posted: Fri May 03, 2024 6:21 pm Post subject: |
|
|
Banana: Thank you for the links.
I tried two of the listed solutions without success.
However, I notice that in xterm when running a CLI program (ex: mail) when backspace does not work and I receive a ^H that <ctrl>backspace does work. |
|
| Back to top |
|
|
mmogilvi
n00b
Joined: 13 May 2011
Posts: 63
|
| Posted: Fri May 24, 2024 11:03 pm Post subject: |
|
|
This is currently happening for any program run in an xterm that uses the tty in its basic "cooked" mode (subject to stty settings). The simplest such program is "cat".
It also happens with programs that might interactively ask for confirmation, such as "emerge -a", "cp -i", etc. You occasionally mistype the confirmation and try to use backspace, and encounter difficulties. These conditions are rare enough you might go weeks before realizing that backspace isn't working properly, which makes tracking down what changed more difficult... Similarly, if a no-echo password prompt fails, you are likely to conclude you lost track of what characters/backspaces you were typing, rather than conclude that backspace isn't actually working. In contrast, some common programs like "bash" and "vim" run the terminal in "raw" mode and (depending on lots of config details) often interpret both ^H and ^? in ways that hide that things are inconsistent elsewhere...
In gentoo, I think it was broken by a recent ncurses update changing the default "kbs" setting in the "xterm" terminfo database. This DB setting typically becomes the default "stty erase" setting:
| Code: | $ cat
abc^H^H^C
$ infocmp xterm | grep kbs
ka3=\EOy, kb2=\EOu, kbeg=\EOE, kbs=^?, kc1=\EOq, kc3=\EOs,
$ stty --all | grep erase
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
$ |
If I run infocmp in an intentionally-old unupdated chroot from 2020, I get "^H" instead of "^?", although I suspect this change is much more recent than 2020.
There seems to be a long-standing disagreement about whether the backspace key should mean "^H" or "^?". But I think it is definitely a gentoo bug when the default setting in the ncurses DB entry and xterm program's default behavior are not consistent with each other in a single install. I think gentoo should fix this inconsistency somehow, but I'm not sure how. There are several possibilities with different nuances... (Maybe someone should file a bug...)
Speculation: Perhaps the terminfo change was an attempt to resolve historically inconsistent "xterm" entries between different OS's? But my searches haven't found anything to indicate there is currently any such effort. In fact, ncurses has long seemed to punt on the issue, to the point where there is apparently a build-time configure option "--with-xterm-kbs" to switch it around (although gentoo's ncurses ebuilds do not seem to use it, and I haven't tried it myself). I was initially concerned that ssh-ing between machines could cause similar issues if the terminfo entries are different, although some testing suggests ssh copies the local "stty erase" setting over to the remote machine by default, which minimizes problems. (There could still be problems if some rare applications trust terminfo over "stty erase"...)
Background:
There are three conceptual settings that ideally should be consistent with each other:
- Which byte/character does xterm generate and feed to the pseudo-terminal when you press the backspace key?
- The terminfo "kbs" setting.
- The stty "erase" setting, which controls which byte/character a "cooked" mode terminal (in kernel) and/or most "raw" mode programs actually treat like a backspace.
Xterm and stty need to be consistent with each other. Most programs don't really care about the terminfo "kbs" setting directly, which allows ssh's copying of the stty setting to usually work even if "kbs" is inconsistent. But occasionally you could encounter programs where "kbs" does matter.
Settings and User Workarounds
- Use Control-Backspace instead of Backspace, as previously mentioned. (awkward)
- Use Control-LeftMouse to bring up a menu in xterm, and toggle the "Backarrow Key (BS/DEL)" option, which is called "backarrowKey" or DECBKM in the man page. (temporary)
- There are at least three X resource properties that xterm uses to control this. See "man xterm" page, especially the sections about "backarrowKeyIsErase", "backarrowKey", "ptyInitialErase", and "ttyMode".
- The interaction of xterm properties is complicated, but the most promising looks like "backarrowKeyIsErase". If set to true with others left as default, it looks like it makes the sent character and the initial/default stty erase setting match the current terminfo kbs DB entry, so everything is consistent, and will presumably still be consistent (toggled everywhere) even if a later update toggles the DB entry again. I'm not sure why it isn't the default. Maybe because there is apparently a DECBKM control sequence that a program can send to xterm to change the behavior of the backspace key, and "true" disables that sequence? But I don't understand why a program (or the program's user) would ever want to use such a sequence.
- TLDR maybe-best user workaround: Try putting "xterm*backarrowKeyIsErase: true" in your ~/.Xresources file (and/or maybe .Xdefaults). Not sure if you need to arrange to "xrdb -merge ~/.Xresources" yourself or not, and/or logout/login, but you definitely need to restart your xterms.
- "stty erase ^H" will also work for this specific case, but could break other cases, like if logged into the Linux console instead of an xterm, or anything else that uses ^?. This command could be placed in .profile or maybe .bashrc, possibly protected by checking various environment variables like "TERM", "SSH_*", "XTERM_*", etc...
- https://bugs.archlinux.org/task/74379 shows how to replace the "kbs" setting in the terminfo database, but of course that will be lost the next time you emerge ncurses...
- Maybe experiment with modifying the "--with-xterm-kbs" config option? But that requires customizing the ebuild...
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Portage & Programming
