4

xterm:

$ echo $TERM
xterm-256color
$ stty -a
speed 38400 baud; rows 52; columns 91; line = 0;
intr = ^C; quit = ^\; erase = ^H; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>;
swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V;
flush = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany
-imaxbel iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke

gnome-terminal:

$ echo $TERM
xterm-256color
$ stty -a
speed 38400 baud; rows 57; columns 100; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = M-^?; eol2 = M-^?; swtch = M-^?;
start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 hupcl -cstopb cread -clocal -crtscts
-ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc ixany imaxbel
iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke

When outside tmux, Ctrl-v Ctrl-h outputs ^H. Inside tmux, I start getting ^? if run from xterm. Inside screen run from xterm it still outputs ^H. What's the reason behind this? Should it output ^H or ^?? How to remedy this?

Improve this question
1
  • 1
    Just to clarify, ^H is backspace (0x08) and ^? is DEL (0x7f). Commented Jan 20, 2015 at 17:35

3 Answers 3

Reset to default
7

The reason is that in your xterm, ^H is the erase character, and tmux apparently translates the erase character to the corresponding control character (^?) for the terminal it emulates, so that erasing works as expected in cooked mode (for instance, what happens when you just type cat). The translation is needed in case you use a terminal with ^? as the erase character (generated by the Backspace key), then resume the session with a terminal that uses ^H as the erase character (generated by the Backspace key). Unfortunately this has visible side effects in some cases, e.g. if you type Ctrl+H.

The only good remedy is to make sure that all your terminals (real or in tmux) use the same erase character, which should be ^? (this is standard nowadays). It seems that your xterm is badly configured. This is not the default configuration, AFAIK.

In any case, you need to make sure to use a TERM value for which kbs=\177. However this is not the case for xterm-256color from the official ncurses. So, you either need to select a different TERM value or you need to fix the kbs entry for xterm-256color (this can be done by the end user with: infocmp > file, modify file, then tic file). Some Linux distributions do not have this problem; for instance, Debian has fixed this problem via a debian/xterm.ti file in its ncurses source package, giving:

$ infocmp xterm-256color | grep kbs
        kbs=\177, kcbt=\E[Z, kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC,

You should also have:

$ appres XTerm | grep backarrowKeyIsErase:
*backarrowKeyIsErase:   true

Note that you can do stty erase '^?' in xterm (before doing anything else), but this is just a workaround (and it may break the behavior of the Backspace key). You should actually have erase = ^? (as shown by stty -a) by default!

In case problems with Backspace and/or Delete remain, I recommend the Consistent BackSpace and Delete Configuration document by Anne Baretta.

Improve this answer
20
  • Could you elaborate on "so that erasing works as expected in cooked mode" part? Who and in which turn processes inputted keys? This is not the default configuration, AFAIK. I don't seem to configure it this way, and it's arch linux, so it's unlikely coming from distribution... Commented Jan 20, 2015 at 19:24
  • you need to make sure to use a TERM value for which kbs=\177; this is true for xterm-256color: And now that is false, but it is as it should be, isn't it? Or your terminfo database might be not so fresh. So, "misconfiguration" must be coming from terminfo database in the end. Commented Jan 20, 2015 at 19:26
  • A relevant link. Commented Jan 20, 2015 at 19:39
  • @x-yuri Hmm... Indeed the official ncurses still has ^H for xterm-256color, and Debian has a fix (difficult to see since this is not via a patch). I've edited my answer to correct that and say what can be done in your case. I've also added an example for the cooked mode. Commented Jan 20, 2015 at 22:29
  • Actually, the part about "cooked mode" became even more fuzzy. It's still not clear from your explanation why tmux has to translate ^H to ^?. But that must be because tmux emulates screen, which has erase = ^? in tmux (but not in terminfo again). I expected you to elaborate on how inputted keys are processed. Say, I press Ctrl-h. Then the pressed key is processed by xterm. Then, by tmux, which translates it. Or when tmux is running, xterm doesn't do any processing? Commented Jan 21, 2015 at 8:40
7

None of the solutions here or elsewhere worked for me. What did work was adding the following to my $HOME/.tmux.conf file:

bind-key -n Bspace send-keys C-h

which makes tmux send Ctrl-H when Backspace is pressed.

I provide some comments, background, and rants below, so feel free to stop reading here. -:)

I disagree with vinc17 that the "only good remedy" is to make the backspace / erase character only be ^?. The user should be able to configure things as he or she see's fit.

A common solution for many of us using Unixes since the days of actual terminals was to use ^H for Backspace and ^? for DEL (i.e., delete after cursor, not before). The distinction between Ctrl-H and Backspace was and is not always necessary, especially for CLI / terminal programs.

I've been using this mapping of ^H / ^? to Backspace / DEL keys (respectively) since the late '80's, on many machines and both for terminal programs and virtual consoles since the "death" of real terminals, and had no desire to reconfigure my erase character on all my machines and those of my clients (many, many machines) to make Backspace sending ^? work.

I tried all sorts of methods based on all sorts of posts to get tmux to send a Ctrl-H for Backspace. In particular, "bind-key -n C-h send-keys C-h" not working frustrated me, as I use tmux within Terminator, and I know that my Terminator is set to send Ctrl-H when the Backspace key is pressed. It took quite a while to stumble upon a post listing the tmux key names available, which is where I found the Bspace keyname, and fortunately that worked to get the ^H character to passthrough tmux correctly (tmux version 2.1-3build1 on Ubuntu 16.04.02).

Improve this answer
1
  • the bind-key command in this solution also causes ctrl-h to correctly be sent when typing c-h, and the keyboard backspace to correctly be <del>. Commented Jul 6, 2020 at 19:20
5

After switching to xterm because of slow-scrolling in xfce4-terminal, I had this same problem. In ~/.Xresources, I set XTerm*ptyInitialErase: true . See the xterm man page. This setting leaves the ^H vs. ^? to the pseudo-terminal. To test this, I did Ctrl-V Ctrl-H and indeed this outputs ^H.

Improve this answer
2
  • This was the answer that helped me the most. If you always start xterm in tmux (xterm -e tmux [...]), using stty in your bashrc won't help; tmux would insert ^? when Ctrl-H was pressed, due to the tty settings of the terminal where it was started. Running stty within tmux does nothing to affect how this works. Xterm needs to START with correct erase settings to get tmux to work the same. Commented Jan 19, 2017 at 16:26
  • Thanks! I also had to set XTerm*backarrowKeyIsErase: true to get backspace working again. Commented Mar 27, 2018 at 15:23

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.