Como Janis mencionou, redirecionar a saída do comando para um arquivo de log é padrão prática. Muitos dos meus scripts de shell começam com:
exec 1>>logfile
exec 2>&1
Observe o uso de >>
para anexar ao arquivo de log. Além disso, o redirecionamento funciona com qualquer shell compatível com POSIX.
Redirecionamento ao executar um shell interativo
Na minha experiência, a única desvantagem de usar exec
para redirecionar o padrão
saída e erro padrão é que você pode perder sua sessão de shell:
Você pode redirecionar facilmente a saída padrão para um arquivo enquanto
shell interativo. Depois de executar exec 1>outfile
, todos os comandos futuros serão impressos
sua saída para outfile
em vez de para o terminal.
Depois de executar exec 2>errorfile
, o erro padrão produzido por qualquer outra
comandos são gravados no arquivo de erro redirecionado - como esperado. No entanto, o problema é que a partir de agora , o shell (Bash, neste caso) imprime seu prompt para este arquivo e
qualquer texto digitado como um comando também é redirecionado para este arquivo. Para o resto de
a sessão de shell, você está essencialmente trabalhando cego como nada é
enviado para o terminal, o que obviamente torna muito difícil continuar
interagindo com o shell.
Como o Orion aponta, você pode armazenar uma referência para o padrão stdout
e
stderr
de descritores de arquivos antes de experimentar esses experimentos usando exec 3>&1
e
exec 4>&2
, respectivamente. Quando terminar suas experiências, você pode
restaurar a impressão para erro padrão executando exec 2>&4
e restaurar
imprimindo na saída padrão com exec 1>&3
.