Bash – How to Emulate a TTY to Preserve Piped Color Output

bashcolorslesspipetty

When you pipe something through less, the program usually discards color codes because it's not outputting to a TTY. So you have to add --color=always to the options for it to work.

ls -l --color=always | less
grep -R asdf --color=always | less

What's worse is that sometimes things don't even support that option, so there's actually no way to force color output to a pipe.

Is there a (relatively) easy way to make less emulate a TTY so that I don't have to specify --color=always to every program when things get piped to it, and it automatically displays color output when possible?

Best Answer

It's not less that needs to change. The output of your other programs is being redirected to a pipe. Those programs detect that their output is not being sent to a tty and they disable their coloring. You're stuck with having to do something special with the source programs to color their output even when redirected to a pipe.

I think I have a solution for the programs that do not support a --color=always option. The unbuffer command creates a pty and sends the output of its argument program to that pty, therefore the argument program thinks its output is going to a tty and colors it.

I tried the following as an experiment and it worked. I couldn't think of any programs that color their output by default.

$ unbuffer ls --color=auto | cat

Also, don't you have to use the -r option with less to get it to display color? I also tried this:

$ unbuffer ls --color=auto | less -r

Related Solutions

Mercurial. Colour output piped to less

For mercurial, you should use the pager extension rather than piping explicitly to less. This will play nicely with the colored output options of other hg commands.

PHP output piped to ‘less’ is requiring after every command

Edit:

Found the solution: You need to do a < /dev/null after the PHP command:

php -r 'for ($i=0; $i<300; $i++) { print "$i\n";}' < /dev/null | less

Apparently PHP behaves differently because it still expects input from stdin.
With the < /dev/null you force PHP into thinking there is no further input.

Edit 2:

If you don't want to (keep) typing the < /dev/null you can create an alias for php2 or something:

alias php2="php < /dev/null`

You can make this permanent if you add it in your ~/.bashrc.

Now you can do:

php2 -r 'for ($i=0; $i<300; $i++) { print "$i\n";}' | less

You could alias php to itself but then you'll never have the ability to pipe something into php.
You could of course shorten it to p (for less typing).

Original answer:

The bug is also present in CentOS 6.5.

A newly installed CentOS 6.5 has it too (in a VM). A ... | cat | less does not work.
A ... > a && cat a | less does work. Go figure.

Cursor keys also don't work in php --help | less. They do work in python --help | less. So it must be something in the PHP executable. I think this is a longstanding bug in PHP.

I found a reference to this bug here.

Until it is fixed you need to do a redirect:

php -r 'for ($i=0; $i<300; $i++) { print "$i\n";}' > /tmp/php.txt && cat /tmp/php.txt | less

Best Answer

Related Solutions

Mercurial. Colour output piped to less

PHP output piped to ‘less’ is requiring after every command

Related Question