实际记录的地方，“\e”代表 .inputrc 中的 Alt 键

Question

几天前我学会了，我可以使用

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

避免方向键。现在虽然这很有魅力，但我开始阅读 bash 文档以了解有关 .inputrc 的更多信息。请看一下这个页面（特别是关于键绑定的部分。） https://www.gnu.org/software/bash/manual/html_node/Readline-Init-File-Syntax.html#Readline-Init-File-Syntax \e 被称为“转义字符”。虽然英语不是我的第一语言，但我永远不会认为这可以用来映射 Alt。这是我和文档的持续计划。对我来说，它们在某种程度上更具有示范性而不是解释性。问题是：这些东西实际上写在哪里，以便其他人可以首先知道并提供提示？

Answer 1

Alt密钥到Escape(ASCII 033, "\e")的映射由终端模拟器完成，readline 库（处理~/.inputrc）不参与其中。

问题是无法将实际的按键事件发送到终端中运行的程序；终端会将它们转换为程序可以从 tty 读取的字节序列。

对于 Alt/Meta 键，有两种方法可以做到：

1. 将它映射到 Escape (ASCII 033 / 0x1b) -- 按下Alt-K实际上会发送"\ek",Alt-Shift-K "\eK"等。这是大多数终端模拟器中的默认设置，但它通常是可配置的，如果它已经不是默认设置，您有充分的理由将其设为默认设置.

2. 打开键的 ASCII 值的第 7 位高位 - 按下Alt-K将实际发送0x6b | 0x80 = 0xeb字节，0x6b即 的 ASCII 值"k"。

后者"\M-k"在 readline 绑定中被识别。

而且，它不工作，是可怕的任何多字节语言环境存在损坏的en_US.UTF-8（这是大多数现代系统默认值）。在这样的系统上，终端仿真器可能不会发送原始0xeb字节（它不是有效的 UTF-8 序列，而是二进制垃圾），但可能会将其从 ISO-8859-1 转换为 UTF-8，从而导致"\xc3\xab" = "ë"（e带有分音符) 被Alt-K按下时发送。

但是无论你如何处理过多的选项，如、、 等，readline 都不知道如何映射"ë"回。"\M-k"convert-metaenable-meta-keyinput-meta

即使你能做到，那仍然会被打破，因为人们可能实际上想要输入"ë"并且"ó"不会欣赏那些被处理为不相关的键，比如Alt-K和Alt-S。