Suprimir mensagens 'arquivo truncado' ao usar cauda

Estou seguindo um arquivo de log tail -f messages.loge 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 truncatedquando o arquivo é truncado automaticamente e isso deve acontecer, mas eu só quero tailme mostrar a saída sem essa mensagem truncada.

Eu tentei usar, tail -f messages.log | grep -v truncatedmas ele me mostra a mensagem de qualquer maneira.

Existe algum método para suprimir esta mensagem?

Essa mensagem é emitida no 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 pipefailopção (ativada com set -o pipefail) para esse pipeline relatar o status de saída, tailse falhar. zshe bashtambém pode relatar o status de componentes individuais do pipeline em seu $pipestatus/ $PIPESTATUSarray.

Com zshou bash, você pode usar:

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

Mas tenha cuidado para que o grepcomando não seja aguardado; portanto, as mensagens de erro, se houver, podem ser exibidas após a tailsaída e o shell já começou a executar o próximo comando no script.

Em zsh, você pode resolver isso escrevendo:

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

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

Há um problema adicional com >(PROCESS); quando isso é anexado a um comando externo, o shell pai não aguarda a conclusão do PROCESS e, portanto, um comando imediatamente seguinte não pode contar com a conclusão dos resultados. O problema e a solução são os mesmos descritos na seção MULTIOS na nota Redirection :: . Portanto, em uma versão simplificada do exemplo acima:

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

(observe que nenhum MULTIOS está envolvido), PROCESS será executado de forma assíncrona no que diz respeito ao shell pai. A solução alternativa é:

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

Os processos extras aqui são gerados a partir do shell pai, que aguardará sua conclusão.

Se grepnão se livrar da saída, é mais provável que seja impressa com erro padrão. A maneira mais simples de se livrar disso é simplesmente despejá-lo:

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

Talvez ajude se pode ser corrige a origem desse erro. Isso aconteceu porque algo gravou no arquivo com substituição ">" e não com anexo ">>".