☰

按 Alt+箭頭鍵時列印的字元是？

tag-icon • tag-icon command-line terminal key-mapping
按 Alt+箭頭鍵時列印的字元是？

當我按 時AltUp，A列印到終端螢幕。當我按下AltDown但B列印時發生了同樣的事情。

我認識的其他角色；

AltLeft=D和AltRight=C

這些命令的目的是什麼？

答案1

根據終端的配置方式，鍵入Alt+Key就像按順序鍵入Esc和Key鍵，因此它會發送 ESC 字元（又名\e或^[或\033），後面跟著按該字元或字元序列時發送的字元或字元序列Key。

按 後Up，大多數終端模擬器會發送三個字元\033[A或\033OA取決於它們是否處於應用程式鍵盤模式。

第一個確實對應於輸出到終端時將遊標向上移動的轉義序列。如果你這樣做：

printf '\nfoo\033[Abar\n\n'

上一行bar後你會看到寫的。foo如果你這樣做：

stty -echoctl; tput rmkx; read foo

您會看到箭頭鍵確實可以移動遊標。

當應用程式喜歡zsh或vi從終端機讀取該字元序列時，它會將其解釋為「向上」操作，因為它從 terminfo 資料庫（kcuu1功能）知道它是按 時發送的轉義序列Up。

現在，Alt-Up一些終端喜歡rxvt及其衍生產品，例如etermsend\033後跟轉義序列 for Up（即\033\033[A或\033\033OA），而其他一些終端則喜歡xterm或在與, ,gnome-terminal等組合鍵一起使用時為這些類型的鍵提供單獨的轉義序列。AltShiftCtrl

這些通常會\033[1;3A在 上發送Alt-Up。

當傳送到終端時，此序列也會向上移動遊標（第二個參數 (3) 被忽略）。沒有對應的鍵盤Alt-Up鍵，因此它與傳入或傳出時發送的序列相同應用程式鍵盤模式。

現在，無論是\033\033[A還是\033[1;3A，許多應用程式都不知道這些序列的用途。 terminfo 資料庫不會幫助他們，因為沒有這樣的功能來定義這些組合鍵發送的字元。

他們將盡力解釋該序列。bash例如將解釋\033[1;3為轉義序列，對此一無所知，因此什麼都不做，後面跟著A. zsh，一旦發現沒有已知的匹配字元序列，就會停止讀取。它不知道以什麼開頭的轉義序列，\033[1因此它將跳過該序列，並讀取其餘部分：;3A並將其插入行編輯器中。

許多應用程式（例如vi,zsh或readline基於gdb或 的應用程式bash（儘管要注意bash使用 的修改版本readline））允許您為任何字元序列新增綁定。

例如，在 中zsh，您可能想要綁定Alt-Up，Alt-Down例如：

bindkey '\e[1;3A' history-beginning-search-backward
bindkey '\e[1;3B' history-beginning-search-forward

這些是向後和向前搜尋歷史記錄，以查找從當前命令列開始一直到遊標當前位置的命令行，這對於呼叫先前的命令非常方便。

答案2

您可以使用Crtl+v返回鍵盤的輸入代碼。如果您對箭頭鍵執行此操作，您將獲得[[D^、[[C^、[[A^和[[B值。 + 箭頭鍵沒有任何預設綁定Alt，因此執行的操作似乎只是單獨列印字母代碼。但是，如果您建立本機版本的 readline 庫設定檔：

$ cp /etc/inputrc ~/.inputrc

並新增一行：

"\e[1;3C": "sometexthere"

+[1;3C的輸入代碼在哪裡（您可以像使用+快捷鍵之前一樣獲取它）並重新啟動終端，然後+快捷鍵將返回文字“sometexthere”，其他+arrow 快捷鍵將停止返回字元。Alt→CrtlvCrtl→Alt

相反，您可以傳遞可綁定命令http://www.gnu.org/software/bash/manual/html_node/Bindable-Readline-Commands.html#Bindable-Readline-Commands喜歡

"\e[1;3C": unix-line-discard

具有與Crtl+ u（刪除行）相同的效果。

更多資訊請點這裡：http://cnswww.cns.cwru.edu/php/chet/readline/readline.html

答案3

此Alt密鑰通常用作元修飾符。遊標鍵和功能鍵稱為特殊鍵因為它們可能會發送多個字元 - 並且發送的字元可以更改。

例如，一些用戶期望bash按下Alt將發送以轉義字元為前綴的鍵。記錄的“元”功能（參見terminfo(5)) 處理第八位：

如果終端機有一個充當 Shift 鍵的“元鍵”，設定傳輸的任何字元的第 8 位，則可以用以下命令表示這一事實：km。否則，軟體將假定第 8 位是奇偶校驗位，並且通常會被清除。如果存在字串可以將其轉變為“元模式” 打開和關閉，它們可以表示為smm和rmm。

bash也知道這一點（參見ncurses 常見問題解答），但很少有用戶對該功能感興趣。儘管如此，Alt即使元模式已關閉，他們還是習慣於稱為“元”。 rxvt 和 xterm 自（至少）20 世紀 90 年代初以來就具有此功能。

其他用戶（自xterm引入該功能以來補丁 #94, 1999）可能期望修飾符資訊被編碼為特殊鍵將發送的字元序列中的參數。 XTerm 的文檔將這些修改後的鍵稱為“PC風格”功能鍵來區分它們“VT220式”（沒有修飾符）。未修改的遊標鍵可能會發送ESC[A，但擁有範圍，例如ESC[5A，哪個應用程式應該理解為重複五次。xterm的第一個版本電腦風格鍵使用“5”來表示control，後來的版本對其進行了更改以避免與重複計數混淆。所以...

ESC[5A

建議應用程式將遊標向上移動 5 行，同時

ESC[1;5A

建議它向上移動一行，告訴應用程式control按下了某個鍵。

有用的組合已在 ncurses terminfo 資料庫中2004年:

# 2004-07-17
#       * add xterm-pc-fkeys -TD

terminfo 資料庫顯示目前版本xterm+pcfkeys帶有顯示修飾符如何編碼的註釋：

# This fragment describes as much of XFree86 xterm's "pc-style" function
# keys as will fit into terminfo's 60 function keys.
# From ctlseqs.ms:
#    Code     Modifiers
#  ---------------------------------
#     2       Shift
#     3       Alt
#     4       Shift + Alt
#     5       Control
#     6       Shift + Control
#     7       Alt + Control
#     8       Shift + Alt + Control
#  ---------------------------------
# The meta key may also be used as a modifier in this scheme, adding another
# bit to the parameter.

（Alt 和 Meta 不一定是同一個鍵）。這是一個積木（依序由其他構建塊組成）xterm終端描述已形成。它使用 ncurses 中提供的擴展自1999年以來它允許用戶定義名稱。由於 termcap 僅支援 2 個字元的名稱和 1023 位元組的描述，因此沒有理由通過術語帽介面.它們很容易被使用的應用程式使用術語訊息介面.

現在出現了一個困難：應用程式可以透過幾種方法來確定這樣的按鍵序列代表什麼：

  1. 完整分析字元序列
  2. control對其進行部分分析，如果不需要則丟棄修改器
  3. 只需將字元序列與字典進行比較，希望能夠透過這種方式確定含義。

很少有程式能做到第一個；一些文字編輯器會做第二個（實際上，我做了這為了ded在裡面1980年代末）。諸如此類的應用程式的開發人員bash選擇了第三條路線，假設大部分資訊都在術語帽。或者，他們可以選擇製作一個包含 termcap/terminfo 資訊的表格，並使用提供最佳資訊的介面。 xterm這樣做是為了tcap 查詢功能，提供vim實際的功能鍵分配。

由於進行比較的字串都不bash匹配它接收到的字串，因此它可能會感到困惑，從而滿足部分匹配（例如轉義字元本身）。

延伸閱讀：

相關內容