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.
Explanation:
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
#IfWinActive
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.
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.
I think they are confused because you are running PopOS and Manjaro. It was not clear to me at first that your were running them headless, or at least just using an SSH session to the tty. With that said, if the system is not running headless on the back end, then that could be a possible issue. But you seem to be sure that they are headless, so I would just ignore that bit. But, do you know if they are running any logon manager like KDM, GDM, LightDM, and etc? If so, there there is a basic part of the DE that is still handling input.
In General, I think you are on the right path, as I had mentioned, you would need to recompile your terminal emulator (in this case PuTTY > xterm emulation) to get your desired output since I believe you are fighting a Unix-like-ism, where CTRL is handled differently than MS Windows (and maybe OSX, because reasons).
I agree, I think there is definitely room for miscommunication in a post this large. I did have the OS, PuTTY, xterm, and showkey -a results all within 2 sentences as quoted though, right below a section header “What I have tried & learned”. I am sure, in the least, that Amazon Linux is headless, and provides the same terminal emulator response over the same PuTTY configuration.
I’ll have to look into the logon manager. I’m running most things stock, as pitched by the main links on the distribution’s site, so Pop!_OS is running Gnome & GDM3, and Manjaro Xfce, but is powered off at the moment so I’m not sure which login manager it ships with.
Still, the last few days of using AHK to override the hotkey sent only when I have PuTTY open has been working very seamlessly. I’ll keep checking this post and replying because I really would like to learn more about this chain of communication, and I don’t mind doing research and running tests to get there. That said, I’m kind of at a dead end with my own knowledge about terminal emulators, especially as it concerns the handling of key combinations, which is why I’m here; I’m hoping someone knows something about this that can either teach me directly or point me in the right direction.
Clearly something is weird here on the chain in between my keyboard and the results of Ctrl-V or showkey -a (which both return the same results in every test I have run), yet local WSL returns what is expected, so I would even limit the scope to the application making the connection to the server, and the server running the keystroke to stdout application. I think what’s left here is: PuTTY (and its potential configuration options), xterm (terminal emulator, including xterm configs), and that’s about it. Are there any other links? I think the DE or login manager is not one, when operating over SSH, since I get the same results xterm environment variable on Amazon Linux which has no file at /etc/X11/default-display-manager.