Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: multios stripping colors?
On 31/01/18 11:30 PM, Oliver Kiddle wrote:
Ray Andrews wrote:
$ eval "$@"
That line in a function of mine can successfully eat some very complex
input including various pipes and color codes. However, when I try this:
eval "eats" only shell syntax. Colour codes are eaten by your
terminal. Perhaps you contrived to prevent them being generated or
constructed something to filter them out.
Of course. Here's a current example:
_execute aptitude search \'$iinst ?description($1)\' '|'
egrep --color \'^\|$1\ $ggrep_oneline\'
'_execute' is a function that contains the above 'eval' plus a few other
things. As I run it with the line just above, I get 'aptitude' output
colored via egrep ....
$ eval "$@" >&2 >! /tmp/_output
Although I do get both outputs, the screen looses all colorized output
... but again, if I do it this way the output to the screen goes B&W.
There is nothing intrinsic to your construct that loses colour escape
sequences. Try the following:
eval "print -P '%K{blue}Hello'" >&2 >! /tmp/_output
cat /tmp/_output
This should give you a blue background from both commands.
Right, so it does.
So you might need to take a closer look at exactly what argument you are
passing to eval.
Some commands, make coloured output conditional on whether their
standard output points to a terminal. For an example, try:
git log | cat
Maybe that's it. So is 'aptitude' or 'egrep' itself determining that
color is not to be had due to the double output? Sounds likely, I know
that the greps all behave differently when receiving piped input than
when not. And I'm correct that if one output is modified the other will
be too?
Thanks, I'll play with it a bit more.
=======================
Oliver
Messages sorted by:
Reverse Date,
Date,
Thread,
Author