Удобная работа в консоли, или красим STDERR в красный цвет

[@Daedmen]

Имхо патчить bash это не трушный хак, так же как и использовать LD_PRELOAD для таких целей, тем более что можно вот так:
color()(set -o pipefail;"$@" 2>&1>&3|sed $'s,.*,\e[31m&\e[m,'>&2)3>&1
color command -program -args
нашел я это когда-то вот тут stackoverflow.com/a/16178979/3056072

[@youROCK]

Дело в том, что таким образом работают не все команды, к сожалению (например «color (echo Hello world)» уже не будет работать). Хотя, кого я обманываю, можно было всего-лишь написать так в .bashrc:

color()(set -o pipefail;"$@" 2>&1>&3|sed $'s,.*,\e[31m&\e[m,'>&2)3>&1

if [ ! -z "$PS1" ] && [ -z "$MY_BASH" ]; then
    export MY_BASH=1
    color bash -l "$@"
    exit "$?"
fi

Правда, если так написать, то почему-то не видно приглашение… Но идея всё равно такая — можно было спокойно обойтись враппером над bash.

[@AAS]

На что только люди не идут лишь бы не использовать ZSH.

[@JIghtuse]

По поводу алиасов: вещь удобная, но странно её применять для git, он обладает своей мощной системой алиасов и автодополнения www.git-scm.com/book/en/Git-Basics-Tips-and-Tricks#Git-Aliases

Патчить bash, несомненно, круто, но можно просто изменить переменную PROMPT_COMMAND:

export PROMPT_COMMAND='ret=$?; if [ $ret -ne 0 ] ; then echo -e "returned \033[01;31m$ret\033[00;00m"; fi'

Тогда ошибки будут отображаться следующим образом:

Скрытый текст

UPD. А, красным у вас подсвечивается stderr. Тогда, пожалуй, патч может быть оправданным. Только не всех это устроит, раздражает.

[@youROCK]

На самом деле, в выложенной версии на github есть возможность определить свои переменные окружения STDERR_PREFIX и STDERR_SUFFIX, и тогда эти строки будут добавляться в начало и конец stderr, вместо красного по умолчанию.

[@youROCK]

Алиасы git хороши всем, кроме того, что всё равно требуется писать целых 4 буквы — собственно «git » ;)

[@Zagrebelion]

alias g=git

[@fshp]

Пробел это не буква.

[@ZyXI]

Зачем вы патчите bash? Есть малоизвестная (в частности, отсутствующая в репозиториях debian и ubuntu) программа hilite которая подкрашивает stderr в красный цвет (к сожалению, только в него: никаких настроек). Если у вас Gentoo, то соответствующий пакет есть в основном дереве portage. Запускать надо как hilite {shell} [args].

[@xaizek]

Интересная штука, только как-то она не заводится. Видно только ошибки красным цветом, выводимый командами текст и вводимый текст, в котором сломана обработка специальных символов, т.е. сломано приглашение командной строки. Проверял без конфигов. Вы с bash её используете?

[@youROCK]

Кстати говоря, в готовом решении, которое предложено в статье (stderred), в исходном коде стоит исключение для процесса bash :), видимо как раз из-за подобных проблем.

[@ZyXI]

С zsh. Иногда и с bash, но он запускается из zsh изредка для тестов чего‐либо, потому имеет приглашение по‐умолчанию. Оно и ввод подсвечиваются красным в bash. Проблем не замечал.
В частности, работает echo $'\e[32mabc' >&2: stderr подсвечивается зелёным, как и было запрошено.
Также работает PS1="\\[^[[32m\\]$PS1" в bash: приглашение подсвечивается зелёным, проблем с определением длины отображаемой строки у bash нет. Работает и source ~/.vam/powerline/powerline/bindings/bash/powerline.sh: получаю приглашение ко вводу, предоставляемое powerline без каких‐либо заметных проблем.

[@ZyXI]

Это если, конечно, не считать подсветку пользовательского ввода красным проблемой.

[@youROCK]

Честно скажу: если бы это было мне действительно нужно для работы, я бы скорее всего воспользовался каким-нибудь готовым решением :). Но так уж получилось, что это делалось for fun в пятницу вечером. Способ решения проблемы выбирался по принципу «чем ближе к ядру, тем лучше», поэтому было решено не писать обертку над bash, а пропатчить собственно сам bash :).

[@xaizek]

Не могу удержаться от того, чтобы не указать на пару моментов в коде. Я понимаю, это не вина автора статьи, что такие огрехи широко распространены, но, возможно, уменьшение их количества станет его заслугой :-)

Используйте, пожалуйста, константы вместо чисел для обозначения стандартных потоков ввода/вывода

Например, здесь используется число 2:

data.err = dup(2);

В то врема как заголовок unistd.h содержит:

/* Standard file descriptors.  */
#define	STDIN_FILENO	0	/* Standard input.  */
#define	STDOUT_FILENO	1	/* Standard output.  */
#define	STDERR_FILENO	2	/* Standard error output.  */

Указатель на void автоматически преобразовывается к любому другому неконстантному указателю

Участки подобные этому:

struct stderr_thread_data* data = (struct stderr_thread_data*)void_thread_args; int n; char buf[1024];

Можно переписать так:

struct stderr_thread_data* data = void_thread_args; int n; char buf[1024];

Это важный момент не только для уменьшения дублирования кода, но и ещё из-за того, что такое преобразование может скрыть ошибки при модификации кода в будущем.

P.S. Ещё раз, знаю что эта статья, вероятно, не лучшее место для подобных комментариев, но очень уж хочеться уменьшить количество подобного кода в проектах с открытым исходным кодом, а тут речь идёт как раз о патче для одного из них.