Это сообщение выводится на 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)
Дополнительные процессы здесь порождаются из родительской оболочки, которая будет ожидать их завершения.
(
)
над сложной командой{
}
?