Restaurando a saída para o terminal depois de ter emitido “exec & filename”

Question

Estou tentando executar o seguinte:

exec &>filename

Depois disso, não consigo ver nada, incluindo o que eu digitei, tudo bem.

Eu tentei freneticamente, exec 1>&1 e exec 2>&2 , mas nada acontece.

Agora, sem matar o shell, como faço para voltar a saída redirecionada para o stdout e erro redirecionado para stderr respectivamente? Os descritores de arquivos são a única maneira de referenciar o padrão [in | out] put e stderr?

    

Answer 1

Depois de executar exec &>filename , a saída padrão e o erro padrão do shell vão para filename . A entrada padrão é o descritor de arquivo 0 por definição, e a saída padrão é fd 1 e o erro padrão é fd 2.

Um descritor de arquivo não é redirecionado ou não redirecionado: ele sempre vai para algum lugar (supondo que o processo tenha este descritor aberto). Redirecionar um descritor de arquivo significa mudar para onde ele vai. Quando você executou exec &>filename , stdout e stderr foram anteriormente conectados ao terminal e se conectaram a filename .

Há sempre uma maneira de se referir ao terminal atual: /dev/tty . Quando um processo abre este arquivo, significa sempre o terminal de controle do processo, o que for . Então, se você quiser recuperar stdout e stderr originais do shell, você pode fazer isso porque o arquivo ao qual eles estavam conectados ainda está por aí.

exec &>/dev/tty

    

Answer 2

Você quer

exec &>$(tty)

O que você está fazendo em sua pergunta é replicar em stdout e stderr o stdout e stderr original que já foram redirecionados para o arquivo.

Como a resposta de Gilles explica, tty retornará o terminal do terminal atual. É aqui que os três descritores de arquivo padrão vêm de / por padrão em um shell de login. Portanto, a declaração acima faz uso de tty para redirecionar stdout e stderr de volta para o terminal como era antes.

Se você estiver preocupado com a portabilidade (conforme seu comentário sobre a resposta de Gilles), os dois métodos (o e o /dev/tty file ) estão no padrão POSIX.

Textatos copiados do comentário de Gilles:

There's an advantage to /dev/tty: it works even after exec <somefile, 
whereas $(tty) would complain “not a tty”