coloring stderr - was Re: piping stderr

[Atom Smasher <atom@xxxxxxxxxxx>]

this has me thinking about an old problem... coloring stderr. the two 
problems i've found previously are (1) keeping stdout and stderr in sync, 
and (2) stderr that doesn't end with a newline, such as messages from "rm 
-i".

this [below] fixes the second problem, but it's still got some unintended 
consequences... the problem i'm having now with it is that if i start bash 
as a child of zsh, bash is a bit messed up. if i start a bourne shell 
(which doesn't actually exist on most/all linux distros, so don't bother 
testing it there) i can see that PS1 is going through stderr, as it's 
being piped the zsh's "color_err" function. if i start a few levels of zsh 
children all with this function, i'm not even sure i want to know how ugly 
things are under the hood. of course all children of the process will have 
their stderr going through this, but with interactive applications that 
can result in some weird stuff...

## colorize std_err
zmodload zsh/terminfo zsh/system
autoload colors is-at-least
if [[ "${terminfo[colors]}" -ge 8 ]] { colors }
color_err () {
   ## sysread & syswrite are part of zsh/system
    while sysread std_err_color
    do
      syswrite -o 2 "${fg_bold[red]}${std_err_color}${terminfo[sgr0]}"
    done
}
## i'm not sure exactly how far back it's safe to go with this
## 4.3.4 works; 4.2.1 hangs.
is-at-least 4.3.4 && exec 2> >( color_err )


-- 
         ...atom

  ________________________
  http://atom.smasher.org/
  762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808
  -------------------------------------------------

 	"I believe that banking institutions are more dangerous
 	 to our liberties than standing armies."
 		-- Thomas Jefferson