Supprimer les messages «fichier tronqué» lors de l'utilisation de tail

J'utilise un fichier journal en utilisant tail -f messages.loget cela fait partie de la sortie:

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.

Il montre tail: messages.log: file truncatedquand le fichier est tronqué automatiquement et c'est censé se produire, mais je veux juste me tailmontrer la sortie sans ce message tronqué.

J'ai essayé d'utiliser tail -f messages.log | grep -v truncatedmais ça me montre quand même le message.

Existe-t-il une méthode pour supprimer ce message?

Ce message est sorti sur stderr comme tous les messages d'avertissement et d'erreur.

Vous pouvez soit supprimer toute la sortie d'erreur:

tail -f file 2> /dev/null

Ou pour filtrer uniquement les messages d'erreur qui contiennent truncate:

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

Cela signifie cependant que vous perdez le statut de sortie de tail. Quelques shells ont une pipefailoption (activée avec set -o pipefail) pour que ce pipeline signale l'état de sortie en tailcas d'échec. zshet bashpeut également signaler l'état des composants individuels du pipeline dans leur $pipestatus/ $PIPESTATUSarray.

Avec zshou bash, vous pouvez utiliser:

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

Mais attention, la grepcommande n'est pas attendue, donc les messages d'erreur le cas échéant peuvent finir par s'afficher après la tailfermeture et le shell a déjà commencé à exécuter la commande suivante dans le script.

Dans zsh, vous pouvez résoudre ce problème en l'écrivant:

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

Cela est discuté dans la zshdocumentation à info zsh 'Process Substitution':

Il y a un problème supplémentaire avec >(PROCESS); lorsqu'il est attaché à une commande externe, le shell parent n'attend pas la fin de PROCESS et par conséquent, une commande immédiatement suivante ne peut pas se fier aux résultats. Le problème et la solution sont les mêmes que ceux décrits dans la section MULTIOS dans la note Redirection :: . D'où dans une version simplifiée de l'exemple ci-dessus:

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

(notez qu'aucun MULTIOS n'est impliqué), PROCESS sera exécuté de manière asynchrone en ce qui concerne le shell parent. La solution de contournement est la suivante:

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

Les processus supplémentaires ici sont générés à partir du shell parent qui attendra leur achèvement.

Si grepne se débarrasse pas de la sortie, elle est très probablement imprimée sur une erreur standard. Le moyen le plus simple de s'en débarrasser est de simplement le vider:

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

Peut-être aider si peut être corrigé l'origine de cette erreur. Cela est arrivé parce que quelque chose écrit dans un fichier avec écraser ">" et non avec ajouter ">>".