GNU 화면 "명령 문자"를 정의하기 위한 포괄적인 가능성 세트를 제공하는 방법은 무엇입니까?

GNU 화면 "명령 문자"를 정의하기 위한 포괄적인 가능성 세트를 제공하는 방법은 무엇입니까?

나는 표준 기성 "US 키보드"와 특정 터미널 에뮬레이터 모두에 대해 GNU 화면 "명령 문자"를 설정하는 가능한 모든 방법을 갖춘 포괄적인 "메뉴"를 생성하고 싶습니다.xfce4 터미널.

나는 이 가능성의 세계가 세 가지 목록으로 분류될 것이라고 상상합니다.

  • 목록escape: 지시문의 가능한 모든 값
  • 목록두번째<CODE>: 표현식의 매개변수에 대해 가능한 모든 값 bindkey -k <CODE> command과 "빈 설정"(즉, 지시문을 사용 .screenrc하지 않는 구성 bindkey -k <CODE> command)
  • 목록: 임의의 쌍(두번째) (어디 ε , 그리고두번째 ε 두번째)에게입력 방법에 대한 명시적인 설명표준 US 키보드의 해당 GNU 화면 명령 문자 및 특정 터미널 에뮬레이터(IOW, "누르기와 동시에 누르기 Ctrl" 와 동일 \)를 가정합니다.

그러나 이러한 규범은 누군가(나)의 진정한 "최선의 노력"이라는 것을 기억하십시오.근본적인 기본을 이해하지 못함. 나는 그것들을 희망한다하다이러한 기본 사항을 이해하면 "줄 사이를 읽고" 문제의 정신을 유지하면서 필요에 따라 이러한 사양을 수정할 수 있습니다(참조배경) 문제를 더 쉽게 처리할 수 있도록 합니다.

나는 내가 원하는 "메뉴"가 상당히 클 것이라는 점을 깨달았지만 표준 미국 키보드의 키 수는 제한되어 있고 크지 않으며 손가락 세트가 있기 때문에 그렇게 까다롭지 않을 것이라고 생각했습니다. 이 목적으로 사용될 수 있다는 것은 훨씬 더 사실입니다. (중요하다면, 각각 최대 3개의 키를 갖는 최대 2개의 연속적인 "메인 코드"로 구성된 키 조합에만 관심이 있다고 추가로 명시할 수 있습니다. "메인 코드"란 "메인 코드의 수를 설정한다는 의미입니다. 키를 동시에 눌렀습니다.").


배경

(일명 tl; 박사)

이 질문은 실제로 Giles의 의견에 대한 후속 조치입니다.전에 시작한 스레드. 그 리뷰에서 말한 내용 중 많은 부분이 내 이해를 넘어서는 것으로 나타났습니다. 나는 여기의 기본 사항에 대한 나의 이해에 큰 격차가 있다고 생각합니다. 사실 너무 커서 그것을 채울 만큼 명확한 질문을 공식화할 수도 없습니다.

Ctrl간단히 말해서, 예를 들어 + 키 조합은 \GNU 화면의 "명령 문자"를 입력하는 데 사용할 수 있지만 (어쩌면) Ctrl+ 와 같은 다른 유사한 키 조합 '은 사용할 수 없다는 것이 나에게는 큰 미스테리입니다.

나 같은 사용자가 기본 기본 사항을 명확하게 이해하지 못하는 경우 적합한 GNU 화면 명령 문자 검색은 일련의 격리된 제안("Ctrl+어때요 H? 결국, 아무도 그것을 다른 용도로 사용하지 않습니다.”), 사용자는 수용 가능한 결과가 나타날 때까지 차례로 평가합니다.

이 일련의 권장 사항 및 평가가 계속되어야 하는 기간은 해당 사용자가 허용할 수 있는 키 조합 세트의 크기에 따라 다릅니다. 분명히 이 크기는 사용자마다 다릅니다. 내 경우에는 평균보다 작은 것 같아서 이 접근 방식으로는 아직 허용 가능한 GNU 화면 "명령 문자"를 제공하지 못했습니다.

그럼에도 불구하고, 이 접근 방식은 본질적으로 비효율적이라고 생각됩니다. 나에게는 잘 정의된 가능성의 "우주"(즉, "완전한 집합")에서 최상의 옵션을 선택할 수 있다는 것이 더 합리적입니다. 그것이 내가 여기서 달성하려고 하는 것입니다.


편집하다:\0001좋아, 몇 가지 연구 끝에 이제 와 (포함) \0177사이의 ASCII 범위에서 (1바이트) 문자를 입력하는 방법을 명확하게 이해하게 되었습니다 . 여기에는 모든 "실제" "제어 문자"가 포함됩니다.

또한 내 생각에 목록은\0001는 과 사이에 있는 모든 가능한 정수 쌍으로 설명될 수 있지만 \0377, 이러한 쌍 중 다수가 완전히 비실용적이라고 배제될 수도 있습니다. (예를 들어 쌍의 첫 번째 요소는 "e" 또는 "8"과 같은 일반적인 "인쇄 가능한 문자"입니다.)

나는 아직도 다음 사항을 알아내려고 노력하고 있습니다.

  • \0200ASCII 범위 \0377(포함)에서 (1바이트) 문자를 입력하는 방법은 터미널과 터미널 에뮬레이터 간에 약간의 차이가 있을 것으로 예상되지만 현재로서는 이러한 차이점이 얼마나 혼란스러운지 모르겠습니다. 캐릭터 실질적인 합의에 도달했나요? 그렇다면 이 문자가 무엇인지(그리고 어떻게 입력하는지) 알고 싶습니다.

  • 목록의 유용한 값을 얻는 방법두번째;이러한 값이 코드라는 것을 알고 있습니다 . 여기서 어려운 점은 편리한 키 조합에 깔끔하게 매핑되는 코드를 termcap식별할 방법이 없다는 것입니다 . 코드는 단일 키에 매핑됩니다. 그렇게 명확한 연결은 없습니다.termcapF2F12termcap

  • 목록을 완성하는 방법, 심지어특정 터미널 에뮬레이터의 경우, 목록에 "빈 설정"이 있음두번째.


1제발, 이 미스터리를 나에게 설명하려고 하지 마십시오. 지식이 풍부하고 인내심이 많은 많은 사람들이 시도했지만 여전히 이해하지 못합니다. 무슨 일이 일어나고 있는지 아는 사람들과 나와 사이의 "지식 격차"가 너무 커서 그들이 해결하려는 질문만큼 그들의 답변이 항상 나를 당황하게 만들었습니다. 내가 이 글을 통해 얻고자 하는 것은 바로이러한 엄청난 지식 격차 해소, 본질적으로 문제를 규정된 유한한 가능성 집합을 구성하는 알고리즘에 대한 검색으로 처리함으로써 기본 기본 사항에 대한 지식이 없는 사람이라도 알고리즘을 구현할 수 있습니다.

답변1

이 질문에 대한 답을 이해하려면 키보드 입력이 처리되는 방식을 어느 정도 이해해야 합니다. 꼭 가보시길 추천드려요키보드 입력과 텍스트 출력은 어떻게 작동합니까?배경. 이 답변에서는 관련 부분을 다르게 설명하지만 이전 답변을 통해 일반적인 친숙함이 있다고 가정하겠습니다.

여기서 내 대답은 일반적인 UNIX 시스템을 의미합니다. UNIX 시스템이 아닌 경우에는 다르게 동작할 수 있습니다. 나는 여기저기서 몇 가지 단순화를 할 것입니다. 추가적인 복잡성은 이 질문에 대답하는 것과 관련이 없습니다. (이 답변은 충분히 복잡합니다.)

터미널 기반 애플리케이션과 터미널(하드웨어 또는 소프트웨어) 간의 통신을 포함한 대부분의 통신 및 저장은 바이트 스트림의 형태를 취합니다. ㅏ바이트이는 256개의 서로 다른 값을 가질 수 있는 정보 단위이며, 8개 부분으로 나눌 수도 있습니다.조금. 바이트는 0에서 255 사이의 숫자로 표시됩니다.

정보를 전송하려면 당사자는 해당 정보를 바이트로 인코딩하는 방법에 동의해야 합니다. 문자 스트림을 바이트 스트림으로 인코딩하는 방법에는 여러 가지가 있지만 모든 방법은 다음을 기반으로 합니다.ASCII 코드어떤 식 으로든. ASCII는 0에서 127 사이의 7비트 값과 128자 집합 사이의 대응을 정의합니다. 이로 인해 각 바이트에 사용되지 않은 비트가 남게 됩니다. 이 128개의 문자는 두 가지 범주로 나뉩니다.

  • 인쇄 가능한 문자 95자: 문자(A–Z, 소문자 및 대문자), 숫자(0–9), 공백, 일부 구두점;
  • 33제어 문자.

제어 문자는 "커서를 다음 줄로 이동", "벨 울림", "기다려", "안녕" 등과 같이 터미널로 전송되거나 터미널에서 전송되는 명령 및 보조 정보를 인코딩합니다.단말기사용자가 제어 문자를 입력할 수 있는 "Control"(또는 간단히 "Ctrl")이라는 레이블이 붙은 키가 도입되었습니다. 터미널의 전자 장치를 단순하게 유지하기 위해 Ctrl키와 함께 누르면 일반적으로 문자가 전송하는 바이트 값에서 간단한 비트 마스크가 수행됩니다. 예를 들어, 바이트 65(바이너리의 경우 1000001)로 표시되는 문자를 전송하고 A+ 바이트 값 1(바이너리의 경우 0000001)로 표시되는 문자를 전송하는 경우 일반적으로 다음과 같이 작성되는 "control-A" 문자를 사용합니다.ACtrlA^A

대부분의 제어 문자는 대문자에 해당하며 비트 패턴은 10xxxxx이고 비트 6은 1 대신 0으로 설정됩니다. 이는 26개에 달합니다. 추가 6개의 제어 문자는 구두점 문자에 해당하며 10xxxxx 형식의 비트 패턴도 갖습니다 @[\]^_.ASCII 인쇄 가능한 문자표. 0~31 범위 외에도 문자 127도 제어 문자입니다. 이를 "control-?"( ?0111111, control-?는 1111111)이라고 합니다.

수년에 걸쳐 ASCII가 아닌 바이트 값에는 다른 의미가 할당되었습니다. 세계는 하나의 방향으로 수렴되고 있다유니코드누구나 원하는 모든 캐릭터의 모음입니다. 유닉스 세계(그리고 인터넷)는 대부분 표준화되었습니다.UTF-8문자를 바이트 시퀀스로 인코딩하는 방법입니다. UTF-8은 0~127 범위의 모든 바이트에 ASCII와 동일한 문자를 할당하고 128~255 범위의 2~4바이트 시퀀스를 사용하여 약 백만 개의 다른 문자와의 호환성을 나타냄으로써 이를 유지합니다. Unix 세계에는 몇 가지 다른 문자 인코딩이 사용됩니다. 대부분은 ASCII를 기반으로 하며 128 이상의 바이트에 대해 다른 의미를 갖습니다.

이제 후속 질문 중 하나에 답변할 수 있습니다.

\0200ASCII 범위(1바이트)의 문자를 입력하는 방법\0377

이는 사용하는 문자 인코딩에 따라 다릅니다. 가장 일반적인 UTF-8을 사용하는 경우 이러한 개별 바이트는 단일 문자를 나타내는 2~4바이트 시퀀스의 일부로만 사용되기 때문에 전송이 불가능합니다.

에 관해서는

목록 Aescape: 지시문의 가능한 모든 값

이것은 단지 바이트 값입니다. 이 escape명령어에는 2바이트 매개변수가 필요합니다. Screen이 터미널로부터 첫 번째 바이트 값을 받으면 Esc 키를 눌렀다고 판단합니다. 터미널에서 보낸 다음 바이트가 escape설정의 두 번째 바이트인 경우 Screen은 첫 번째 바이트를 Screen 창 내에서 실행되는 응용 프로그램으로 보낼지 결정합니다.

설명bind주문하다Screen이 이해할 수 있는 방식으로 바이트 값을 지정하는 방법을 설명합니다. 문서에 "문자"라고 적혀 있으면 대신 "바이트"를 읽어보세요.

리스트 B에 들어가기 전에 먼저 핵심 코드를 이해해야 합니다. 키 코드는 등과 같은 수정자와 함께 키를 누르는 것 Ctrl입니다 Shift. 앞서 터미널에서 전송된 모든 정보가 바이트 스트림으로 인코딩된다는 것을 살펴보았습니다. 단순화를 위해 인쇄 가능한 모든 문자는 표준 방식으로 인코딩됩니다. 즉, ASCII 문자인 경우 32~126 범위의 바이트로, 기타 문자의 경우 128~255 범위의 바이트로 인코딩됩니다. 이로 인해 기능 키를 인코딩하는 제어 문자와 이외의 수식자가 있는 문자만 남습니다 Shift. 하지만 제어 문자는 33개뿐이에요!

일부 기능 키는 제어 문자를 보냅니다. 예를 들어, 바이트 9는 프린터가 다음 탭 열로 이동하도록 지시하는 TAB 제어 문자이기 때문에 Tabkeypress는 (바이트 값 9)를 보냅니다 . ^IReturn가 전송됩니다 ^M(바이트 값 13). 바이트 13은 프린터에 헤더를 줄의 시작 부분으로 이동하라고 지시하는 CR 제어 문자이기 때문입니다. 비슷한 이유로 Escape보내고 ^[보내 BackSpace거나 역사적인 엉터리 때문에 여기에 들어가지 않겠습니다 ^H.^?

대부분의 기능 키와 키 및 키는이스케이프 시퀀스: 바이트 27부터 시작하는 바이트 시퀀스,이스케이프 문자(ESC)는 ASCII로 정의되며 ^[(control-[)입니다.다른 터미널은 다른 이스케이프 시퀀스를 보냅니다.. 표준이 있지만 모든 키와 코드에 대한 인코딩을 정의하지는 않으며, 어느 정도 경쟁 표준이 있습니다.

이제 우리는 이해할 준비가 되었습니다.

목록 B<CODE>: 표현식의 매개변수에 대해 가능한 모든 값bindkey -k <CODE>

이것스크린 문서이 코드는 다음과 같다고 설명하세요.용어 모자키보드 기능 이름. Termcap은 애플리케이션이 터미널 간의 차이점을 추상화하는 데 사용할 수 있는 프로그래밍 라이브러리입니다. (지금은 대부분 교체됐지만용어 정보.) Termcap 데이터베이스에는 행 및 열 번호(Termcap이 나타나는 경우 터미널은 하드웨어 장치이며 크기 조정 개념이 적용되지 않음), 바이트 시퀀스(일반적으로 ESC로 시작) 및 응용 프로그램과 같은 터미널에 대한 정보가 구체적으로 포함되어 있습니다. 커서 이동, 화면 지우기 등의 작업과 다양한 키 누름을 통해 전송된 일련의 바이트를 수행하는 데 사용할 수 있습니다. Termcap은 나중에 사용할 수 있는 기능 키에 기호 이름을 제공합니다 bindkey -k.

이것텀캡 매뉴얼이 데이터베이스의 모든 항목을 나열합니다. 이들 항목은 모두 두 글자로 된 이름을 갖고 있습니다; FreeBSD 매뉴얼은 또한 각 항목에 대해 좀 더 표현력 있는 이름을 제공합니다. 첫 번째 열에 FreeBSD에 의해 나열된 항목은 기능 키를 설명하는 항목입니다. for , for , for 등 두 번째 열에 있는 이름입니다.key_SOMETHING<CODE>bindkey -kklLeftk1F1F1F11

데이터베이스에 많은 키와 코드가 누락되어 있음을 알 수 있습니다. 이 데이터베이스에 키나 코드에 대한 항목이 없으면 키에 사용할 수 있는 이름이 없습니다 bindkey -k. 지원되는 키 세트는 UNIX 변형에 따라 다릅니다.

bindkey이스케이프 시퀀스도 전달할 수 있습니다. 이 기능을 사용하려면 관심 있는 키와 코드에 대해 터미널이 보내는 내용을 알아야 합니다. 서로 다른 터미널이 동일한 키와 코드에 대해 서로 다른 이스케이프 시퀀스를 보내더라도 다행스럽게도 이스케이프 시퀀스와 키 코드 사이에는 모호성이 거의 없습니다. 서로 다른 터미널의 서로 다른 키 코드에 해당하는 이스케이프 시퀀스는 거의 없습니다.

Ctrl+ 키를 누른 다음 키 코드를 누르면 키 코드에서 보낸 이스케이프 시퀀스를 확인할 수 있습니다 V. 기본 모드의 터미널과 모든 일반 쉘의 명령줄에서 Ctrl+는 V"다음 바이트를 문자 그대로 해석"을 의미합니다. 뒤에 이스케이프 시퀀스가 ​​오면 이스케이프 시퀀스 구문 분석을 시작하는 대신 ESC 바이트가 문자 그대로 삽입됩니다. 이스케이프 시퀀스는 거의 항상 ESC 다음에 인쇄 가능한 문자로 구성되므로 문자 그대로 이스케이프 시퀀스를 효과적으로 삽입합니다. 예를 들어 Ctrl+ 를 누른 V다음 Ctrl+를 누르면 Left이스케이프 시퀀스 Ctrl+ 가 보내는 내용을 볼 수 있습니다. ESC 제어 문자의 시각적 표현이 어디에 있는지 Left확인할 수 있습니다 . (터미널에서 다른 이스케이프 시퀀스를 다시 보낼 수도 있습니다.)^[O5D^[

null 설정의 경우 Screen이 ESC 바이트를 읽으면 이스케이프 시퀀스 구문 분석 모드로 들어갑니다. 각각의 새로운 바이트는 누적된 이스케이프 시퀀스에 추가됩니다. 누적된 시퀀스에 연결된 바인딩이 있는 경우 Screen은 이스케이프 시퀀스 구문 분석 모드를 종료하고 바인딩을 시작합니다. 누적 시퀀스가 ​​연결된 바인딩이 있는 시퀀스의 접두사가 아닌 경우 Screen은 이스케이프 시퀀스 구문 분석 모드를 종료하고 누적 시퀀스를 삭제합니다. 따라서 여기서 null 설정은 "아무 일도 일어나지 않는다"는 복잡한 형태입니다.

이 모든 작업이 완료되었으면 다음으로 넘어가겠습니다.

목록 C: 임의의 쌍(,두번째) (어디ε, 그리고두번째ε두번째)는 표준 US 키보드에서 해당 GNU 화면 명령 문자를 입력하는 방법을 명시적으로 설명하고 특정 터미널 에뮬레이터의 사용을 가정합니다.

위에서 힌트를 드린 것처럼,특정 터미널 에뮬레이터여기서 중요한 점: 다양한 터미널은 다양한 방식으로 키와 코드를 인코딩하며 일부 터미널은 다른 방식으로 구성될 수 있습니다. 이 매핑은 (,두번째):×두번째흥미로운 컬렉션은 아닙니다. 대부분의 키와 코드는 다음에 매핑됩니다.누구나인쇄 가능한 문자(위에서 본 것처럼 확장됨))또는이스케이프 시퀀스(위에서 본 것처럼 확장됩니다.두번째). 즉, 매핑은 상위 집합에 대한 것입니다.두번째.

불행하게도 많은 터미널은 이스케이프 시퀀스를 보내는 방법을 완전히 문서화하지 않습니다. 다행히도 이는 거의 필요하지 않습니다. 이스케이프 시퀀스에서 키 코드로 이동하지 말고 키 코드에서 이스케이프 시퀀스로 이동하세요. 이는 앞서 설명한 바와 같이 Ctrl+를 이용하여 단말별로 판단할 수 있다 .V

일부 터미널, 특히 xterm은 체계적인 방식으로 키 코드를 인코딩하도록 구성할 수 있습니다. 바라보다터미널 사용 시 키 바인딩 문제Emacs에 대한 토론. 불행하게도 이vte 라이브러리를 포함하지 않습니다.특히 GNOME 세계의 많은 터미널 에뮬레이터에서 사용됩니다.

관련 정보