Подавите 'файл усеченные' сообщения при использовании хвоста

Вот альтернатива, которую я использую. Это громоздко, но он решает проблему, о которой упоминается @ axel _ c, где иногда вы можете захотеть иметь отдельный экземпляр истории в каждом терминале (один для make, один для monitoring, один для vim и т.д.).

Я храню отдельный файл истории, который постоянно обновляю. У меня есть следующее сопоставление с горячей клавишей:

history | grep -v history >> ~/master_history.txt

Это добавляет всю историю с текущего терминала к файлу с именем master_history.txt в вашем домашнем каталоге.

У меня также есть отдельная горячая клавиша для поиска в главном файле истории:

cat /home/toby/master_history.txt | grep -i

Я использую cat | grep, потому что он оставляет курсор в конце для входа в мой regex. Менее уродливым способом сделать это было бы добавить пару сценариев к вашему пути для выполнения этих задач, но горячие клавиши работают в моих целях. Я также периодически буду извлекать историю из других хостов, над которыми я работал, и добавлять эту историю в свой master_history.txt файл.

Всегда приятно уметь быстро искать и находить тот хитрый регекс, который вы использовали, или тот странный один лайнер, который вы придумали 7 месяцев назад.

Если grep не устраняет вывод, он, скорее всего, будет напечатан при стандартной ошибке. Самый простой способ избавиться от этого - просто сбросить его:

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

Это сообщение выводится на stderr , как и все предупреждения и сообщения об ошибках.

Можно либо удалить все выходные данные об ошибках:

tail -f file 2> /dev/null

, либо отфильтровать только те сообщения об ошибках, которые содержат усечение :

{ 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 в примечание Перенаправление:: . Следовательно, в упрощенная версия приведенного выше примера:

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

(обратите внимание, что MULTIOS не задействованы),ПРОЦЕСС будет выполняться асинхронно что касается родительской оболочки. Обходной путь:

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

Дополнительные процессы здесь порождаются из родительской оболочки, которая будет дождаться их завершения.