4 ms·
Or, add this to .zshrc: # colorize all stderr red exec 2>>(while read line; do print '\e[91m'${(q)line}'\e[0m' > /dev/tty; print -n $'\0'; done &) works lik
by apinstein 15y ago
Or, add this to .zshrc:
# colorize all stderr red
exec 2>>(while read line; do
print '\e[91m'${(q)line}'\e[0m' > /dev/tty; print -n $'\0'; done &)
works like a charm.
- 1amzave 15y agoThough I'm not a zsh user, my first reaction was likewise "meh, my shell can do that", and so I whipped up a pretty much identical command (only using sed). However, when it didn't behave quite as I expected, I dug a little deeper and ended up with (what was to me) a curious discovery: bash prints its prompt to stderr rather than stdout (see http://git.savannah.gnu.org/cgit/bash.git/tree/parse.y#n5013 http://git.savannah.gnu.org/cgit/bash.git/tree/parse.y#n5013). Anyone know why it does that?
- burgerbrain 15y agoThat's a great question. Zsh and tcsh both use stdout for their prompt, ksh and dash use stderr for the prompt itself but stdout for whatever the user is typing into the prompt. Bash, at least as it's configured on my system, seems to use stderr for the prompt and whatever the user types on it. I really can't think of a reason that the way tcsh and zsh handle this isn't the proper way. Surely the principle of least surprise applies here.
- sickill 15y agoThis is the solution I started with. However it's messing line order sometimes due to race conditions/buffering.
- apinstein 15y agoYeah we're getting that issue, too. And sometimes the prompt doesn't appear properly.