* multios stripping colors?
@ 2018-02-01 5:11 Ray Andrews
2018-02-01 7:30 ` Oliver Kiddle
0 siblings, 1 reply; 4+ messages in thread
From: Ray Andrews @ 2018-02-01 5:11 UTC (permalink / raw)
To: Zsh Users
All:
$ 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 "$@" >&2 >! /tmp/_output
Although I do get both outputs, the screen looses all colorized output
that was previously there. As I understand the docs, this might be
expected at lest in so far as it seems to say that both outputs must be
created at the same time, thus if there is some reason that color codes
can't be sent to the file, then they won't be sent to the screen either.
Is there anything I can do to get my color back? On the screen at
least. I can send color escapes to a file and thecolors show upwhen the
file is cat-ed, but I'm not sure that the colors as above can be sent to
a file. Can they? Seems to me I remember that they can't.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: multios stripping colors?
2018-02-01 5:11 multios stripping colors? Ray Andrews
@ 2018-02-01 7:30 ` Oliver Kiddle
2018-02-01 15:52 ` Ray Andrews
2018-02-01 16:34 ` Ray Andrews
0 siblings, 2 replies; 4+ messages in thread
From: Oliver Kiddle @ 2018-02-01 7:30 UTC (permalink / raw)
To: Zsh Users
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.
> $ eval "$@" >&2 >! /tmp/_output
>
> Although I do get both outputs, the screen looses all colorized output
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.
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
Oliver
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: multios stripping colors?
2018-02-01 7:30 ` Oliver Kiddle
@ 2018-02-01 15:52 ` Ray Andrews
2018-02-01 16:34 ` Ray Andrews
1 sibling, 0 replies; 4+ messages in thread
From: Ray Andrews @ 2018-02-01 15:52 UTC (permalink / raw)
To: zsh-users
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
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: multios stripping colors?
2018-02-01 7:30 ` Oliver Kiddle
2018-02-01 15:52 ` Ray Andrews
@ 2018-02-01 16:34 ` Ray Andrews
1 sibling, 0 replies; 4+ messages in thread
From: Ray Andrews @ 2018-02-01 16:34 UTC (permalink / raw)
To: zsh-users
On 31/01/18 11:30 PM, Oliver Kiddle wrote:
>
> Some commands, make coloured output conditional on whether their
> standard output points to a terminal. For an example, try:
> git log | cat
>
> Oliver
>
By gum, that's it.
egrep --color=always
... solves the problem. As you say, egrep was trying to be clever
there, detecting the output to the file and killing the color, but you
can force the issue with 'color=always'. Thanks Oliver, there is always
a way.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2018-02-01 16:35 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-02-01 5:11 multios stripping colors? Ray Andrews
2018-02-01 7:30 ` Oliver Kiddle
2018-02-01 15:52 ` Ray Andrews
2018-02-01 16:34 ` Ray Andrews
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).