Это сообщение выводится на stderr, как и все предупреждения и сообщения об ошибках.
Вы можете удалить все сообщения об ошибках:
tail -f file 2> /dev/null
Или отфильтровать только сообщения об ошибках, которые содержат truncate:
{ tail -f file 2>&1 >&3 3>&- | grep -v truncated >&2 3>&-;} 3>&1
Это означает, однако, что вы потеряете статус выхода tail. Несколько оболочек имеют pipefailопцию (включается с помощью set -o pipefail) для этого конвейера, чтобы сообщать о состоянии выхода, tailесли он выходит из строя. zshи bashможет также сообщать о состоянии отдельных компонентов конвейера в их $pipestatus/ $PIPESTATUSмассиве.
С помощью zshили bashвы можете использовать:
tail -f file 2> >(grep -v truncated >&2)
Но имейте в виду, что grepкоманду не ждут, поэтому сообщения об ошибках, если таковые имеются, могут в конечном итоге отображаться после tailвыхода, и оболочка уже запустила следующую команду в сценарии.
В zsh, вы можете обратиться к этому, написав это:
{ tail -f file; } 2> >(grep -v truncated >&2)
Это обсуждается в zshдокументации по адресу info zsh 'Process Substitution':
Есть дополнительная проблема с >(PROCESS); когда это присоединено к внешней команде, родительская оболочка не ждет завершения PROCESS и, следовательно, следующая сразу команда не может полагаться на завершение результатов. Проблема и решение те же, что описаны в разделе MULTIOS в примечании Redirection :: . Следовательно, в упрощенной версии примера выше:
paste <(cut -f1 FILE1) <(cut -f3 FILE2) > >(PROCESS)
(обратите внимание, что MULTIOS не задействованы), PROCESS будет выполняться асинхронно, если это касается родительской оболочки. Обходной путь:
{ paste <(cut -f1 FILE1) <(cut -f3 FILE2) } > >(PROCESS)
Дополнительные процессы здесь порождаются из родительской оболочки, которая будет ожидать их завершения.
()над сложной командой{}?