Terminal emulator/xterm/stty confusion: trying to get Ctrl-Backspace behaving like GUI-native apps


I have found myself in a very dark and silly rabbit hole, trying to save myself a few seconds/minutes over my lifetime by doing hours of research. I’ve been using Linux for many years and usually I just adapt to learn how to do things the Linux way, but this 1 time I thought I’d try to make Linux behave like I want, since my muscle memory is going to press the key combination anyway. This thought has resulted in many hours of searching and 54 open tabs related to this issue, but although I have learned a lot, I still don’t feel any closer to solving the problem. So, I am here to ask for help.

The Problem
I would like to be able to press Ctrl+Backspace and see the functionality “backspace 1 whole word” in the terminal. However, I can’t seem to split my terminal emulator’s understanding of Ctrl+Backspace away from Backspace, which according to showkey -a, both are sending ^?.

Some light background - I know there are simple alternatives available to me right away. Ctrl-W works just fine, and after learning about stty, I found that I can make whatever keystroke I want perform a werase, which works as I like. I just can’t get it working for Ctrl-Backspace.

In GUI-based applications, Ctrl-W is reserved for “close window” function, or in tabbed applications like Notepad++ or your browser, this keystroke will close a tab. I have even gotten Ctrl-Shift-W closing a tab stack in Vivaldi. Ctrl-Backspace is used in these cases to provide the backwards-kill-word or werase functionality in these GUI-based systems. I would like to be able to retain my muscle memory by using these newer keystrokes as previously learned, especially when using GUI-based Linux distributions and switching between the terminal and a browser, for example.

What I have tried & learned

  • showkey -a is a useful command for letting the terminal respond with the (ascii?) input that I sent as seen by the terminal emulator.
  • echo $TERM In theory shows me my terminal emulator. I assume the rest of my OS configuration is being truthful to this variable, but things also get a bit sticky later when I get into tmux.

Given these 2 facts, this is what I have observed:

  1. WSL - fedoraremix, ubuntu, etc. are using xterm-256color and report ^? for Backspace and ^H for Ctrl-Backspace. Looking good.
  2. 2 systems, Pop!_OS and Manjaro based, each report the following over a PuTTY ssh connection: xterm terminal and showkey -a gives ^? for Backspace and ^? for Ctrl-Backspace.

So, that isn’t right. I have come to understand a few things about these results:

  • When the terminal emulator interprets ^? for both key combinations, anything I configure for werase in stty will apply for both key combinations. i.e. both Backspace and Ctrl-Backspace will backwards-delete-word. Hence, I need to resolve the terminal emulator’s interpretation of my key combination before I can select an action/command for that key combination to perform.
  • According to Stack Exchange, tmux will interpret the calling shell’s configuration upon launch. It will however report screen as the running terminal emulator. Hence, I must resolve the terminal emulator’s interpretation of my key combination before I can forward the configuration to tmux.

With this in mind, I first thought to check the PuTTY configuration, and thought I landed on something solid with the Terminal > Keyboard settings, but actually this Backspace key configuration will make things backwards, such that if you set the non-standard Control-H, then Backspace will send ^H, but Ctrl-Backspace will send ^?. This does well to separate the keystrokes, but sends them in the opposite pattern observed on a local shell or WSL as exampled earlier. Without trying to get my nuts in a twist, I undid that and went back to looking.

I did find some pretty good articles on configuring x or xterm, but this is the first time I’ve tried doing so and I’m running into some problems. I like this user’s approach (assigning a totally unused escape sequence), so I tried it first: Use of CtrlBackSpace in xterm
They suggest setting the following configuration in “an X resource”:

*VT100*translations: #override \n\
        Ctrl<Key>BackSpace: string("\033[7;5~")

I had to search some to find that most people these days use ~/.Xresources. My system did not have this file so I created it and added the configuration. Since this was my first time configuring this file, I had to find information about how to reload it for a first-time or test config. I found someone say xrdb -merge ~/.Xresources should do the trick. When I execute this, I get an error xrdb: Can't open display ''. I tried searching this error online but mostly return results on forums asking “which window manager are you using”, but to reiterate I am operating this machine over ssh via PuTTY, which from my understanding does not have a window manager like dwm or i3, because there is no GUI. Is there something silly I’m missing here, like some fundamental assumption about xterm that assumes there will be a GUI?

So… From here I’m not sure where to go. I know I need to resolve the xterm keystroke interpretations, but I can’t even seem to set up a basic ~/.Xresources, even when carefully checking the whitespace or attempting to apply a different background color instead of focusing on my keystroke problem.

If there’s anything I’m doing wrong or anything I can learn, please say it. That’s why I’m here asking for advice. There’s nothing business critical about this, just trying to find a true solution to set my fickle mind at ease, after which maybe I’ll find a way to make the solution into some lovely infrastructure as code via configuration management so I can propagate the configuration to all my machines. I think the ideal solution may also be looking into switching away from PuTTY, since it would leave the terminal emulator to its default config and fix the problem client-side, but that also comes with downsides such as no longer being able to use PuTTY and mRemoteNG. Well, I better end this here as it’s already gotten super long. Thank you sincerely for your time, and any suggestions that you have to offer.

1 Like

You would need to redirect the key stroke so that it registers the CTRL +? to CTRL + H or ^H.

That would most likely mean that you would need to patch your terminal emulator to do so.

I understand this fundamentally. I described the steps I took to attempt this. Can you describe what I’m doing wrong, or rather what I should do correctly in order to implement this?

TL;DR I think you are fighting a feature of the terminal emulator and that you will only be able to fix this by patching the terminal emulator source code.

I don’t think it is you more or less than it is the terminal emulator. There are many layers between the keyboard input and the resultant software layer. I think you have to patch in the source code of the terminal emulator, not the configuration file. The key stroke actually has a default behavior in the Unix world and that may be picked up before your input redirect actually registers. I think only xmod/xmonad is able to grab the standard input and actually convert it to something else at the input stream level.

If you are using a DE, you may be able to set up the keyboard shortcut in the DE and then that may also change some key mappings, but what you have done should be more than enough, as long as the native key command does not already mean something int the terminal emulator.

I did see another reference to xmodmap, which looks like it should do what you described. I’ll have to look at xmod/xmonad to understand their functionality. If any of these rely on the xrdb command though, I suspect I’ll run into the same error mentioned previously xrdb: Can't open display ''

I’ll do some research into these commands. I don’t think it seems reasonable to recompile my terminal emulator. I’d like this to be something configured or manipulated only for my user, so that I could use the configuration at work as well.

Well, the beauty of F/LOSS is that you can do what ever you want with the code. At the very least, I would reach out to the maintainer of your terminal emulator and see if they will entertain a feature request. At the very least if you come up with a viable solution on your own, you could submit a PR to the maintainers to get it mainlined.

It couldn’t hurt! I don’t know Typscript though, so it might be a rough time for me to get a PR ready.

Woah! I think I just put together a really elegant work-around (at least for me and my use case)!

I found some people saying that PuTTY doesn’t support all the proper inputs. Some suggested using KiTTY, but this is problematic for me since I like to use mRemoteNG, which uses a PuTTY fork, PuTTYNG. I looked into why they were saying it, and found that PuTTY doesn’t have a way to configure Ctrl modifier nicely. I thought “that’s pretty lame” and started looking into suggested solutions.

1 person suggests using AutoHotkey. I use a lot of AutoHotkey functions already, so I looked into modifying his code to work for my purpose. I figured the easiest solution would be to remap to the already built-in Ctrl-w, so I went with that.

; mRemoteNG remap Ctrl-Backspace to Ctrl-w
#IfWinActive ahk_class PuTTYNG
^Backspace::SendInput, ^w

For users of regular PuTTY, just delete the NG. I’ve already inspected the ahk_class to validate.

I’m curious if this method will have any negative effects long-term, such as if an application like vim or emacs or something interprets Ctrl-w differently than xterm. I also imagine that this may come to bite me when I’m doing occasional RDP connections, but that is fairly rare for me.

Even the default stty, at least for my system, werase is set to ^W, so I can now remove the ^H configuration and stop trying to figure out how to reconfigure xterm.

Unrelated curiousity, the original suggestion sent some ASCII instead like {esc}[1;2D. {esc} is AHK for the escape key, but I don’t understand what [1;2D sends. Anyone know a resource I can look up to understand how to convert this ASCII to something readable? Although AHK documentation suggests a different way to send ASCII.

edit > nvm about the potential RDP issue. ahk_class for that is WindowsForms10.Window.8.app.0.3b93019_r7_ad1, or may be different for different Windows versions given that weird string.

key binding in linux

dunno if this is applicable. but you may be able to set up a macro/keybind…

I looked at bind. The problem is I can’t tell bind how to differently interpret ^? and ^?, even though in reality I sent different keystrokes.

It works well for native terminals though, just not PuTTY.

have you checked to see what xterm is set in the config for putty?
same for tmux. you may be able to set it to xterm-256colour

tmux show -g | cat > ~/.tmux.conf

sorry i dont have linux open so i cant point you to the files.

yes, PuTTY is set to Terminal-type string: xterm

Still, according to my research, PuTTY does not have a native configuration to interpret Ctrl based keystrokes differently. It will send stuff like Ctrl-H just fine, but not Ctrl-Backspace, Ctrl-Enter, etc. And there are limited ways to reconfigure this. Everything I had tried made things go entirely backwards so that I would have to reconfigure every PuTTY client I have and every server to prevent unintended behavior.

yeah ctrl+backspace will likely need escaping and its not doing it correctly due to your keyboard layout or its not an alpha numeric key, same with enter.

maybe try whats suggested here? ^^

I don’t think it’s a layout problem, since WSL (same machine but local) showkey -a interprets it perfectly in multiple distributions. This is why targeting PuTTY’s failure to interpret the keystroke differently has resulted in a pretty decent work-around for my setup by using AHK.

I reviewed the article, but I’m not sure what you’re suggesting. STRG key appears to be a thing on German layouts.

For anyone to be able to help you, it’s necessary to start with the basics… What OS you’re using, what desktop environment, what terminal emulator, etc.

XTerm is a GUI application for X11. It’s only a slight exaggeration to say that essentially all terminal emulators are graphical applications.

Basic context on your situation would really help others to understand why/where you are having trouble.

Maybe you didn’t read my whole post, as I gave all of this information. I understand, it’s very long, because I have already put a lot of effort in on my own to solve this. Is there a standard layout I should have posted it in? Can you direct me to that documentation perhaps? If so, I’m happy to reformat the original post.

I’ve read your whole post… I have no idea which OS you’re using as your desktop. I see absolutely no mentions of any desktop (GUI) environment. You specifically say you’re not using any window manager, trying to run xterm without a GUI, etc., all of which makes no sense.

Just as something to think about, there is a precedence in which different programs will handle the input. On most computers the desktop environment (DE) like e.g. Gnome, XFCE, i3, kde, will handle the input using Xorg or Wayland window compositors. As long as none of the key combinations are applied by the DE they are handed to the/any program displayed in a window i.e. you terminal emulator. This means based on the DE what you receive on the terminal emulator can already wary. Normally terminal emulators have their own sets of key combinations they react to. When you quit your DE however, you are also presented with a terminal emulator. This however is where the terminology becomes unclearer. This is normally a basic terminal emulator/shell. In most cases not the one you would use in a window in a DE.

OS: Pop!_OS and Manjaro. Both of these I’m using the default shipped DE, but again that doesn’t matter because I mentioned (again as seen in the quote above) PuTTY to open SSH connections to these hosts and run the tests. When I echo $TERM (again, over SSH), it returns xterm.

I think I understand what you’re saying, but I’m missing something about why everyone is so keen on the DE I’m using and how it’s interpreting commands. When running a server OS, would it not be true that no DE is even installed? Is it not similar that, when operating over an SSH connection, that no DE is initialized for the session?

As an example, I connected to an Amazon Linux shell via SSH, and run echo $TERM, which still returns xterm. From everything I understand and research, there is no DE installed on this image.

I believe this is the true issue, as KiTTY has been offered as a valid work-around to this kind of issue, by sending Ctrl- based keystrokes, you can have different behavior based on the configuration options available in PuTTY and KiTTY.