Pergunta sobre o comportamento de atalhos de teclas de controle

Question

Estou confuso sobre como Ctrl-key combinações funcionam no terminal. Na página man bash, existem várias combinações, como:

• C-e - ir para o final da linha
• C-f - vai um caractere para a frente

etc.

Mas há alguns atalhos não documentados , como:

• C-j (OU C-m ) para a chave de retorno.
• C-h para backspace
• C-i para a guia etc.

Esses atalhos são esquecidos para serem documentados? Ou porque

• C-j é LF
• C-m é CR
• C-i é Tab

em ASCII, isso é um comportamento "padrão"? Em outras palavras, o comportamento de C-j , C-m e C-i não foi implementado por bash, mas por alguma outra coisa?

Outra pergunta é, quando pressiono C-v e a tecla de seta para a esquerda, ^[[D aparece na tela. Por exemplo, ESC-[-d . Mas quando pressiono ESC-[-d , o cursor não se move para a esquerda. Qual é a razão para isso?

EDITAR:

Inicialmente, pensei que quando pressiono C-j , o teclado envia diretamente 00001010 para o kernel. Mas depois decidi que esse não é o caso, porque usando programas como xev ou evtest , observei que as teclas pressionadas para Control e j aparecem como eventos diferentes. Então, quando eu pressiono C-j , o teclado não envia 00001010 , mas provavelmente vários bytes. Então, onde a conversão desses múltiplos bytes para 00001010 é feita?

    

Answer 1

O comportamento de C-m , C-i , etc. é implementado por bash, mas o fato de que eles são a mesma coisa que Retorna , Tab , etc. é devido ao comportamento do terminal. Todos os terminais se comportam assim porque todos os terminais sempre se comportaram assim e é o que as aplicações esperam. A interface entre um terminal e um aplicativo é baseada em caracteres (na verdade, bytes), não em chaves, portanto, chaves que não enviam caracteres imprimíveis e combinações de teclas precisam ser codificadas de alguma forma. Consulte Como a entrada de teclado e a saída de texto funcionam? para mais sobre este assunto. Consulte também link

TAB é o caractere de tabulação em ASCII , e é a mesma coisa que o caractere Ctrl + I em ASCII . Da mesma forma para as outras chaves. Os terminais enviam esse caractere quando o usuário pressiona a tecla Tab e quando o usuário pressiona Ctrl + I . Idem para RET (CR) e C-m , para LFD e C-j (que a maioria dos teclados não possui) e para ESC e C-[ . Há também BackSpace que envia C-h ou C-? , o que é um problema.

A configuração do terminal ( stty settings) também pode ser usada, e isso afeta algumas das configurações do bash (por exemplo, após stty erase @ , o bash tratará pressionando @ como BackSpace), mas não C-m e C-j para enviar a linha atual.

^[[D é Esc [ D , mas com um% mai D . Se você pressionar Esc [ D , o bash verá a tecla Esquerda , devido à declaração das seqüências de escape da chave do cursor no termcap ou terminfo banco de dados. Não há nenhuma ligação padrão para Esc [ d (não é uma seqüência de escape que os terminais comuns enviam).

    

Answer 2

Duas perguntas, dois pontos:

• controle / J , controle / M e controle / I são controles ASCII comuns que a maioria dos programas assume. bash simplesmente facilita a religação em readline.

• a maioria dos programas que aceitam chaves especiais, como a seta para a esquerda, fornecem uma maneira de reconhecer a chave de escape distinguida dessas chaves especiais por tempo . Você provavelmente não pode digitar rápido o suficiente para inserir os caracteres (exceto para casos especiais como o emacs, que não não prestam atenção ao tempo).

  Como você não digita tão rápido, o programa vê os caracteres separados, que não movem o cursor. Os caracteres separados podem fazer algo interessante.

Independentemente disso (notando um comentário sobre um erro de digitação que eu negligenciei na questão), ESC [ d é uma seqüência de controle padrão , que, se enviado para um terminal, moveria o cursor para a linha superior da tela:

CSI Pm d  Line Position Absolute  [row] (default = [1,column]) (VPA).

Como o xterm implementa isso , qualquer coisa que se pareça com o xterm fará o mesmo, curso. O console do Linux faz isso também. No entanto, bash geralmente não faz eco às sequências de controle: o comportamento observado é o mesmo que bash faz com as fugas que não reconhece.

Em relação a feeds de formulário (um comentário pressupõe que eles são parte da pergunta): o uso de bash do form-feed (para entrada ) para limpar a tela configura algumas pessoas (incluindo desenvolvedores do PuTTY) para supor que os terminais devem interpretar um feed de formulário. Esse recurso realmente vem de impressoras de linha e originalmente era raramente encontrado em terminais, até mesmo na variedade de impressão. Para alguma discussão relacionada, consulte minhas anotações em um repaginador e acompanhamentos para reutilizar o recurso.