"shift-tab"이 터미널에서 "Escape"를 발생시키는 이유는 무엇입니까?

Shift+ Tab여러 터미널에서 이와 같은 이스케이프 시퀀스를 보냅니다.

ESC [ Z

Linux 콘솔 터미널에서 사용됩니다.1995년부터, xterm의 일부2002년부터, 그 시점부터 하나 또는 다른 터미널을 에뮬레이트하는 데 사용됩니다.

설명 에서 terminfo이는 다음과 같이 표시됩니다.

kcbt=\E[Z,

그리고 kcbt기록된terminfo(5):

key_btab                  kcbt   kB   back-tab key

분석적인 관점에서 이는 기능 키를 누르는 것과 다르지 않습니다. readline에는 키 편집을 위한 몇 가지 특별한 경우가 있습니다(bash의 termcap 문자열 테이블에 의존).lib/readline/terminal.c), 그러나 termcap "kB"은 그중에 없습니다.

추가된 복잡성으로 구성 변경은 다음과 같이 시작됩니다.2007년이로 인해 Linux 콘솔의 Shift-Tab을 누르면 다음과 같은 메시지가 전송됩니다.다른이스케이프 시퀀스, 즉

ESC TAB

이는 2021년에 보고되었으며 터미널 데이터베이스가 수정되었습니다. 그렇게 하면 Emacs 개발자에게 약간의 고통이 따릅니다(참조:메일링 리스트 스레드), 그 프로그램은 "kB"를 확인합니다. 하지만 2022년 5월 현재 문제가 해결된 것으로 보입니다.

어느 쪽이든 bash는 termcap 문자열을 무시합니다.

bash에 termcap 정보가 없으면 에 의존합니다 .inputrc. 어느 쪽에서도 일치하는 항목이 없으면 ESC(이스케이프된) 문자는 설명된 대로 삽입 모드를 종료합니다(결국 vi입니다).

---

이에 사용되는 이스케이프 시퀀스는 다음과 같습니다.ECMA-48표준 포스트 탭 제어 순서. 이 내용은 에도 기록되어 있습니다.terminfo(5):

   back_tab                    cbt       bt     back tab (P)

특수 키에 제어 시퀀스로 동일한 이스케이프 시퀀스를 사용하는 것은 완전히 우연이 아닙니다. 하드웨어 터미널은 종종 특수 키를 에코하기 위해 호스트에 의존하지 않고 커서 이동 키가 화면 주위로 커서를 이동하는 로컬 편집 모드를 제공합니다. ncurses 터미널 데이터베이스에 있는 터미널 설명 중 약 절반은 특수 키와 제어 시퀀스 사이의 연관성을 보여줍니다.

 439 entries with cbt == kcbt
  73 entries with clear == kclr
 383 entries with cub1 == kcub1
 505 entries with cud1 == kcud1
 885 entries with cuf1 == kcuf1
 868 entries with cuu1 == kcuu1
 174 entries with dch1 == kdch1
 186 entries with dl1 == kdl1
 502 entries with home == khome
  52 entries with ich1 == kich1
 139 entries with il1 == kil1

cub1터미널 설명은 일반적으로 2-3 문자 제어 시퀀스 대신 1 문자 백스페이스 또는 개행 문자를 사용하기 때문에 and 의 개수는 sum cud1보다 낮습니다 . 그럼에도 불구하고 439개의 게시물 탭은 터미널 설명의 약 4분의 1이 이 특정 기능을 사용하고 있음을 나타냅니다.cuf1cuu1

Linux 콘솔은 먼저 Shift-Tab을 사용하여 백탭 이스케이프 시퀀스를 전송하지 않습니다. 다음과 같은 오래된 항목이 있습니다.앤아버이 기능을 사용하는 AT&T 항목도 마찬가지입니다. 후자는 비트 프로텍터에 대한 설명서가 거의 없지만AT&T 610그리고AT&T 630매뉴얼 제공.

Esc 키로 해석하는 것이 bash보다 더 기본적인 것 같습니다. 어쩌면 독서 라인에 있을까요?

그보다 훨씬 낮습니다. 이는 Unices 및 Unix 계열 운영 체제에서 작동하는 터미널의 필수 속성입니다. 운영 체제는 터미널 I/O를 8비트(또는 7비트) 문자 시퀀스로 처리합니다. 기능 키와 확장 키는 다중 문자 이스케이프 시퀀스로 전송됩니다.

실제 터미널에서 이러한 이스케이프 시퀀스는 터미널 자체의 펌웨어에 의해 생성됩니다. 터미널 에뮬레이터 프로그램에서 터미널 에뮬레이터는 키 입력 데이터(X Window 시스템, USB 숨겨진 장치 또는 Linux 이벤트 장치 등 키보드와 통신하는 사용자 인터페이스를 통해 수신된 데이터)를 이스케이프 시퀀스로 변환합니다.

vim다양한 줄 편집 라이브러리와 같은 응용 프로그램은 Esc이스케이프 문자를 읽는 것과 다음 문자를 읽는 사이의 시간을 (실제로) 타이밍하여 간단한 키 누르기와 구별 하려고 합니다. 문자가 차례로 빠르게 도착하면 이스케이프 시퀀스로 처리됩니다.

이 문서는 어디서 찾을 수 있나요?

입력에서 이스케이프 시퀀스의 시간 초과 처리는 아래 Z Shell의 ZLE 매뉴얼 페이지 vim와 ZLE 매뉴얼 페이지에 문서화되어 있습니다. 이스케이프 시퀀스의 터미널 생성에 대한 기본 아이디어는 널리 문서화되었습니다. :help ttimeoutzshzle

생성된 특정 이스케이프 시퀀스에 대한 문서를 얻기가 어렵습니다. 많은(현재 아마도 대부분의) 터미널(특히 아날로그 터미널)은 DEC VT 터미널이 수년 동안 사용해왔던 이스케이프 시퀀스를 사용합니다(Digital에서 "ANSI 모드"라고 부르는 경우). DEC는 터미널에 대한 문서를 제공하며 ShiftVT525 프로그래머 정보 doco의 8장에서 + 인코딩에 대해 명시적으로 논의하는 내용을 찾을 수 있습니다 .Tab

그러나 터미널 에뮬레이터 프로그램이 운영 체제 커널의 일부인 Linux 또는 BSD에서 커널 가상 터미널을 사용하는 경우 다음과 같은 경우 DEC VT 규칙 준수가 상당히 불안정합니다.입력하다제어 순서. 그 이유 중 하나는 FreeBSD와 같은 운영 체제가 실제로 기본적으로 SCO XENIX 가상 터미널 규칙을 준수하기 때문입니다. 그 결과 실제 터미널과 일치하지 않는 DEC VT와 SCO XENIX의 이상한 혼합이 탄생했습니다.

이 혼합은 단순한 입력 터미널 에뮬레이션과 출력 터미널 에뮬레이션 간의 불일치 이상입니다. 이러한 상황은 최신 구성이 입력 제어 시퀀스에 대해 SCO XENIX 기본값을 무시하려고 시도하지만 부분적으로만 수행된다는 사실로 인해 더욱 악화됩니다. 예를 들어 최근 FreeBSD에서는 커널 터미널 에뮬레이터에서 F6DEC VT 제어 시퀀스가 CSI 1 7 ~​​SCO XENIX 시퀀스로 컴파일되었지만 Shift+는 여전히 DEC VT 제어 시퀀스가 ​​아닌 F6SCO XENIX 제어 시퀀스로 컴파일되어 있음 을 알 수 있습니다 .CSI dCSI 1 7 ; 2 ~

그리고 이것들은 FreeBSD doco에는 전혀 없습니다.

추가 읽기

• VT510 비디오 터미널 프로그래머 정보. EK-VT510-RM. 1993년 11월.
• VT520/VT525 비디오 터미널 프로그래머 정보. EK-VT520-RM. 1994년 7월.