Shell – How to permanently change both STDOUT and STDERR color to grey

colorsosxshellterminal

This question is similar to
Can I configure my shell to print STDERR and STDOUT in different colors?

But I am looking for a solution that will allow me to change both STDOUT and STDERR to ONE color. I am not trying to set different color for STDOUT and STDERR, as this is problematic and may create problems, mentioned in the answer from the link above.

I apologize, as I don't know much about Unix and Linux. I am looking for a solution that can allow me to add couple lines to my .bashrc or .bash_profile and permanently change the color of STDOUT and STDERR.

Best Answer

STDOUT and STDERR don't have colors. What has color is your terminal (emulator); it has one foreground (and one background color) set at a time.

It should also be noted that STDOUT and STDERR are not singular -- they're per process output streams. There is no global STDOUT that applies to all programs. These streams are routed to your terminal, but they are distinct for each process.

Terminal emulators usually have ways to set the palette via a menu, such that the default foreground (applied to data received via both STDOUT and STDERR streams) could be whatever. You can also apply ANSI color codes in your prompt and if you don't reset the color with \[\033[0m\] at the end, it will continue to apply. Note that some applications use these and reset, so this is not a very ideal method, since the reset will go back to the terminal's default.

If setting the terminal foreground is not what you want, you can filter STDOUT/STDERR on a per process basis; see the suggestions here.

Related Solutions

Bash – Why the differences in color between SSH terminal sessions in OSX

Copy this part into you CentOS .bashrc:

# uncomment for a colored prompt, if the terminal has the capability; turned
# off by default to not distract the user: the focus in a terminal window
# should be on the output of commands, not on the prompt
#force_color_prompt=yes

if [ -n "$force_color_prompt" ]; then
    if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then
    # We have color support; assume it's compliant with Ecma-48
    # (ISO/IEC-6429). (Lack of such support is extremely rare, and such
    # a case would tend to support setf rather than setaf.)
    color_prompt=yes
    else
    color_prompt=
    fi
fi

if [ "$color_prompt" = yes ]; then
    PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[    \033[00m\]\$ '
else
    PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
fi
unset color_prompt force_color_prompt

The ${debian_chroot:+($debian_chroot)} part won't work, though and can be removed (but it won't hurt anything by staying there, it just evaluates to an empty string).

Bash – How to capture ordered STDOUT/STDERR and add timestamp/prefixes

You might use coprocesses. Simple wrapper that feeds both outputs of a given command to two sed instances (one for stderr the other for stdout), which do the tagging.

#!/bin/bash
exec 3>&1
coproc SEDo ( sed "s/^/STDOUT: /" >&3 )
exec 4>&2-
coproc SEDe ( sed "s/^/STDERR: /" >&4 )
eval $@ 2>&${SEDe[1]} 1>&${SEDo[1]}
eval exec "${SEDo[1]}>&-"
eval exec "${SEDe[1]}>&-"

Note several things:

It is a magic incantation for many people (including me) - for a reason (see the linked answer below).
There is no guarantee it won't occasionally swap couple of lines - it all depends on scheduling of the coprocesses. Actually, it is almost guaranteed that at some point in time it will. That said, if keeping the order strictly the same, you have to process the data from both stderr and stdin in the same process, otherwise the kernel scheduler can (and will) make a mess of it.

If I understand the problem correctly, it means that you would need to instruct the shell to redirect both streams to one process (which can be done AFAIK). The trouble starts when that process starts deciding what to act upon first - it would have to poll both data sources and at some point get into state where it would be processing one stream and data arrive to both streams before it finishes. And that is exactly where it breaks down. It also means, that wrapping the output syscalls like stderred is probably the only way to achieve your desired outcome (and even then you might have a problem once something becomes multithreaded on a multiprocessor system).

As far as coprocesses be sure to read Stéphane's excellent answer in How do you use the command coproc in Bash? for in depth insight.

Best Answer

Related Solutions

Bash – Why the differences in color between SSH terminal sessions in OSX

Bash – How to capture ordered STDOUT/STDERR and add timestamp/prefixes

Related Question