我正在为 *nix 系统编写一个命令行应用程序。我想将标准输入上的字节转换为输入设备事件，例如“单击左按钮”、“向上滚轮刻度/运动”、“按下 ctrl-alt-shift-leftarrow ”等等。我想在当前使用的虚拟终端上执行此操作，即 xterm、gnome-terminal、linux 内核控制台 (Ctrl-Alt-F1..6)、tmux、ssh 上的任何上述内容等等.
我非常高兴只适应人们在过去 10-20 年里所做的 99% 的事情，也就是说，如果有人将物理 VT100 插入他们的机器，而我的应用程序无法在其上运行，我可以接受那。但是，我想充分利用 xterm 和朋友的功能，并且我希望能够尽可能地知道 stdin 上的字节意味着什么。
如何做到这一点？换句话说，我该如何重新实现 ncurses 的输入子系统？
据我所知，几乎所有终端上的转义按键的表示都是大多数例如的前缀。众所周知，箭头键和功能键转义序列以及非无前缀编码很难消除歧义，尤其是当 M-x 的编码方式与 ESC 后跟 x 相同时；-)
这个小问题现在已提升为命令行 ui 约定，就这样吧，但更令人担忧的是：假设我想构建一个已知转义序列的数据库（以及来自上下文的映射，例如
$TERM据我所知，这几乎是不可能的。
我最好的想法是凭经验进行：建立一个我所知道的所有终端仿真器的列表，为每个仿真器提供所有有效的 X11 键输入，然后看看另一端会输出什么。在某种程度上，终端仿真器的 X-key-to-stdio-bytes 映射是可配置的，这将非常脆弱。但就我所能理解的世界而言，terminfo 大致就是这样。
terminfo（和 termcap）为应用程序提供已知密钥代码的“字典”。但这些词典的大小是有限的。某些终端（模拟器）可以提供比 termcap（1024 字节）或 terminfo（传统格式中的 4096 字节 - 也许 ncurses 中当前的 65536 就足够了）中定义的更多内容。 任何所谓的“现代”终端都将遵循这样的约定：键（
输入）绑定到对应于ECMA-48（仅寻址输出）的东西。造成这种情况的部分原因是按键（特别是光标键）可以在终端的“本地模式”下解释。 很可能，给定的终端模拟器不实现 本地模式（ECMA-48
SRM），但 xterm 做到了。而且因为（兼容性和缺乏创新的结合）其他终端开发商也遵循这种模式。
curses/termcap 应用程序依赖于这个字典，而不对密钥编码的格式做出假设。但是，如果（通过修改curses库或curses/termcap应用程序）选择处理任何未知的字节序列，例如如果它遵循ECMA-48模式，那么这将简化应用程序中的恢复。