A few days ago I learned, that I can use

"\ej": history-search-backward
"\ek": history-search-forward

for avoiding the arrow keys. Now while that works like a charm and i began to read the bash-docs to learn more about .inputrc. Please have a look at this page ( especially the part about keybindings.) https://www.gnu.org/software/bash/manual/html_node/Readline-Init-File-Syntax.html#Readline-Init-File-Syntax \e is mentioned as "an escape character". While english is not my first language I would never assume this could be used to map Alt. That's an ongoing scheme with me and documentation. They somewhat feel more examplatory than explanatory to me. The question is: Where is that stuff actually written down, so that others could have know about and give the Tip in the first place?


The mapping of the Alt key to Escape (ASCII 033, "\e") is done by your terminal emulator, the readline library (which handles the ~/.inputrc) has no part in it.

The problem is that there is no way to send the actual key events to a program running in a terminal; the terminal will convert them into sequences of bytes which the program can read from the tty.

For the Alt/Meta key, there are two ways to do it:

  1. Map it to Escape (ASCII 033 / 0x1b) -- pressing Alt-K will actually send "\ek", Alt-Shift-K "\eK", etc. This is the default in most terminal emulators, but it's usually configurable and you have all the reasons to make it the default if it already isn't.

  2. Turn on the high 7th bit on the ASCII value of the key -- pressing Alt-K will actually send the 0x6b | 0x80 = 0xeb byte, 0x6b being the ASCII value of "k".

It's the latter which is recognized as "\M-k" in readline bindings.

And that does not work and is horribly broken with any multibyte locales like en_US.UTF-8 (which are the default on most modern systems). On such system, the terminal emulator may not send the raw 0xeb byte (which is not a valid UTF-8 sequence, but binary garbage), but may convert it from ISO-8859-1 to UTF-8, resulting in the "\xc3\xab" = "ë" (e with diaeresis) being sent when Alt-K is pressed.

But readline doesn't know how to map "ë" back to "\M-k" no matter how much you fiddle with the plethora of options like convert-meta, enable-meta-key, input-meta, etc.

And even if you could do it, that would still be broken, because people may actually want to type "ë" and "ó" and will not appreciate those being handled as unrelated keys like Alt-K and Alt-S.

| improve this answer | |

You should find that \e is the escape character (meaning there's only one of them, character code 27, often written ESC) rather than an escape character (meaning one of several).

I think in this instance the documentation is trying to say that \e represents an instance of the ESC character, so that one could write \e\e for two ESC characters.

It does not represent ALT.

| improve this answer | |
  • Well, ok, that's exactly what I would have expected when I read it. The funny thing now is the to mappings I stated in the question are actually matching Alt-k and Alt-j. – chalybeum Sep 23 '19 at 19:08
  • These keybindings should also work with Escape key instead of Alt. – Arkadiusz Drabczyk Sep 23 '19 at 19:29
  • No they don't. As I said, that's the weird part of docs sometimes they seem to be just plain wrong. – chalybeum Sep 23 '19 at 19:31
  • 1
    @chalybeum: Did you try? In readline programs, ESC followed by a key is usually equivalent to ALT+key. (e.g. in bash: ALT+. repeats the last parameter from the last command; ESC followed by . does the same thing.) – Nick Matteo Sep 23 '19 at 19:35
  • @chalybeum: yes, they do. Read up on Meta key and read Readline Notation part in man bash. – Arkadiusz Drabczyk Sep 23 '19 at 19:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.