4 comments:

The problem you had was due to git being clever and stripping colors from the output when piped to another command. This is pretty useful since some pagers (like "less") don't understand ANSI colors, so:

$ git diff --color HEAD HEAD^1 | less

becomes a huge mess to see, while:

$ git diff --color=auto HEAD HEAD^1 | less

shows up ok. Same for ls --color=auto. Even "ack" does that very same trick.

For those interested in the implementation, you just test if STDOUT (or STDERR) is opened to a tty, using the -t file test operator. Something like:

# colors only if we're not being piped $ENV{ANSI_COLORS_DISABLED} = 1 if not -t *STDERR;

thanks @garu for your comment, you are right, exept in the 'less' bit. There are some less-terminal-setup that are broken and this does not work, but in my linux systems 'less' accepts the color with a direct pipe or reading a file that have the redirected output. In this last case 'less' ask if I want to open a binary file, I say YES and less show the text with the colors correctly.

But as you say having the color=auto is a good thing and only if I really want the redirection with color I will add the --color option.

@anonymous. Caca labs (despite its scatological naming tendency) has very nice tools like libcaca. But despite I was tempted to explore it, I had the impression that it was going to take me more time that I had for that task. So I tried only the ready made solutions. For example I used H::FA because it has the ready made script. When I have more time I will explore more possibilities and other libraries better. By the way do you have a ready made example using libcaca?