Suprime as mensagens 'arquivo truncado' ao usar a cauda

Question

Estou acompanhando um arquivo de log usando tail -f messages.log e isso faz parte da saída:

Lorem ipsum dolor sit amet, consectetur adipiscing elit. 
Fusce eget tellus sit amet odio porttitor rhoncus. 
Donec consequat diam sit amet tellus viverra pellentesque. 
tail: messages.log: file truncated
Suspendisse at risus id neque pharetra finibus in facilisis ipsum.

Ele mostra tail: messages.log: file truncated quando o arquivo é truncado automaticamente e isso deve acontecer, mas eu só quero que tail mostre a saída sem essa mensagem truncada.

Eu tentei usar tail -f messages.log | grep -v truncated , mas ele mostra a mensagem mesmo assim.

Existe algum método para suprimir esta mensagem?

    

Answer 1

Essa mensagem é enviada em stderr como todas as mensagens de aviso e erro.

Você pode eliminar toda a saída de erro:

tail -f file 2> /dev/null

Ou para filtrar apenas as mensagens de erro que contêm truncate :

{ tail -f file 2>&1 >&3 3>&- | grep -v truncated >&2 3>&-;} 3>&1

Isso significa, no entanto, que você perde o status de saída de tail . Alguns shells têm uma opção pipefail (ativada com set -o pipefail ) para que o pipeline relate o status de saída de tail se falhar. zsh e bash também podem relatar o status de componentes individuais do pipeline na matriz $pipestatus / $PIPESTATUS .

Com zsh ou bash , você pode usar:

tail -f file 2> >(grep -v truncated >&2)

Mas cuidado com o fato de o comando grep não ser aguardado, portanto as mensagens de erro, se houver, podem ser exibidas após o tail sair e o shell já ter iniciado o próximo comando no script.

Em zsh , você pode resolver isso escrevendo:

{ tail -f file; } 2> >(grep -v truncated >&2)

Isso é discutido na documentação zsh em info zsh 'Process Substitution' :

There is an additional problem with >(PROCESS); when this is attached to an external command, the parent shell does not wait for PROCESS to finish and hence an immediately following command cannot rely on the results being complete. The problem and solution are the same as described in the section MULTIOS in note Redirection::. Hence in a simplified version of the example above:

paste <(cut -f1 FILE1) <(cut -f3 FILE2) > >(PROCESS)

(note that no MULTIOS are involved), PROCESS will be run asynchronously as far as the parent shell is concerned. The workaround is:

{ paste <(cut -f1 FILE1) <(cut -f3 FILE2) } > >(PROCESS)

The extra processes here are spawned from the parent shell which will wait for their completion.

    

Answer 2

Se grep não se livrar da saída, é mais provável que esteja sendo impressa no erro padrão. A maneira mais simples de se livrar disso é simplesmente descartá-lo:

tail -f messages.log 2>/dev/null

    

Answer 3

Talvez ajude se pode corrigir a origem desse erro. Isso aconteceu porque algo foi gravado no arquivo com a substituição ">" não com append "> >".