Como o 'less' pega dados do stdin e ainda consegue ler os comandos do usuário?

Question

Como a maioria de vocês já fez muitas vezes, é conveniente ver textos longos usando less :

some_command | less

Agora seu stdin está conectado a um pipe (FIFO). Como ainda pode ler comandos como up / down / quit?

    

Answer 1

Como mencionado por William Pursell , less lê as teclas digitadas pelo usuário no terminal. Ele abre explicitamente /dev/tty , o terminal de controle; que fornece um descritor de arquivo, separado da entrada padrão, a partir do qual ele pode ler a entrada interativa do usuário. Ele pode ler dados simultaneamente para exibir a partir de sua entrada padrão, se necessário. (Também poderia escrever diretamente no terminal, se necessário.)

Você pode ver isso acontecer executando

some_command | strace -o less.trace -e open,read,write less

Movimente-se pela entrada, saia em less e observe o conteúdo de less.trace : você a verá aberta /dev/tty e leia o descritor de arquivo 0 e o que foi retornado quando abriu /dev/tty (provável 3).

Essa é uma prática comum para programas que desejam garantir a leitura e a gravação no terminal. Um exemplo é o SSH, por exemplo. quando ele solicita uma senha ou frase secreta.

Como explicado por schily , se /dev/tty não puder ser aberto, less lerá seu erro padrão (descritor de arquivo 2). O uso de less de /dev/tty foi introduzido na versão 177, lançada em 2 de abril de 1991.

Se você tentar executar cat /dev/tty | less , como sugerido por Hagen von Eitzen , less conseguirá abrir /dev/tty , mas não obterá nenhuma entrada até que cat feche. Assim, você verá a tela em branco e nada mais até pressionar Ctrl C para matar cat (ou eliminá-lo de alguma outra forma); então less mostrará o que você digitou enquanto cat estava em execução e permite que você o controle.

    

Answer 2

O UNIX fornece dois métodos para ler a entrada dos usuários enquanto o stdin foi redirecionado:

• O método original é ler a partir de stderr . O Stderr está aberto para escrever e leitura e isso ainda é mencionado no POSIX.

• Versões posteriores do UNIX fizeram (por volta de 1979) adicionar uma interface de driver /dev/tty que permite abrir o controle de um processo. Como existem processos sem controle tty, é possível que uma tentativa de abrir /dev/tty falhe. O software escrito amigável, portanto, tem um retorno ao método original e, em seguida, tenta ler a partir do stderr.