De acordo com esta resposta de schily , less
lê os comandos de navegação do stderr se não conseguir abrir /dev/tty
.
Isso parece intrigante, já que nunca vi nada gravar no fluxo stderr de outro programa, e não sei como conseguiria isso.
Qual é o propósito do stderr ser aberto tanto para leitura quanto para escrita? E se isso for útil, como faço para usá-lo em sistemas modernos? (Existe alguma sintaxe misteriosa para canalizar algo em stderr em vez de stdin, por exemplo?)
Fiquei surpreso no início. No entanto, depois de ler as respostas e fazer uma pequena investigação, parece simples. Então aqui está o que eu encontrei. (no final não houve surpresa.)
Antes do redirecionamento, stdin, stdout e stderr são, conforme o esperado, conectados ao mesmo dispositivo.
Portanto, após a maioria dos redirecionamentos (ou seja, se stderr) não for redirecionado. stderr ainda está conectado ao terminal. Portanto, pode ser lido, para obter a entrada do teclado.
A única coisa que está parando os arquivos sendo usados na direção inesperada é a convenção, e os pipes são unidirecionais.
Outro exemplo, tente:
Isso dá errado depois de uma página, quando
less
tenta ler o terminal (isso não é uma surpresa, poiscat
também está lendo o terminal)./dev/tty
é mais misterioso, não é um link para/proc/self
.Veja quais são as relações entre meu terminal de controle atual e `/dev/tty`? para uma explicação. Obrigado a @StephenKitt pelo link.
Quando você faz login, stdin, stdout e stderr são conectados ao terminal de onde você faz login. Para ser mais exato, o tty é normalmente aberto e stdout e stderr são o resultado de duas
dup(2)
operações no primeiro descritor de arquivo. Isso permite ler do stderr para obter entrada do terminal.Conforme mencionado na outra resposta, os programas leem do stderr para obter uma resposta interativa em uma pergunta.
Como um usuário não pode saber em quais circunstâncias um programa lê do stderr, é uma tentativa inútil de gravar dados intencionalmente no stderr de outro programa.
Observe que os programas de hoje geralmente tentam primeiro abrir
/dev/tty
e usar o stderr apenas no caso de não funcionar.Programas que lêem apenas de stderr geralmente nunca foram modificados desde antes de 1979 e esses programas geralmente contêm construções como:
ou
que não são aceitos pelos compiladores C modernos. Como resultado, é muito improvável que você encontre hoje um programa que nunca abre
/dev/tty
, mas lê respostas interativas do stderr.