From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2517 invoked by alias); 1 Feb 2018 16:22:29 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: List-Unsubscribe: X-Seq: 23108 Received: (qmail 8502 invoked by uid 1010); 1 Feb 2018 16:22:28 -0000 X-Qmail-Scanner-Diagnostics: from mta04.eastlink.ca by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(24.224.136.10):SA:0(-2.6/5.0):. Processed in 2.571637 secs); 01 Feb 2018 16:22:28 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham autolearn_force=no version=3.4.1 X-Envelope-From: rayandrews@eastlink.ca X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=utf-8; format=flowed X-Authority-Analysis: v=2.3 cv=dfKuI0fe c=1 sm=1 tr=0 a=RnRVsdTsRxS/hkU0yKjOWA==:117 a=RnRVsdTsRxS/hkU0yKjOWA==:17 a=IkcTkHD0fZMA:10 a=Q_jl0r5LA66-obOdM8wA:9 a=QEXdDO2ut3YA:10 X-EL-IP-NOAUTH: 24.207.101.9 Subject: Re: multios stripping colors? To: zsh-users@zsh.org References: <7771fca9-b248-3159-8597-65ddb057214d@eastlink.ca> <13088.1517470216@thecus.kiddle.eu> From: Ray Andrews Message-id: <5be03a10-ffcb-ef96-ed5a-46331d02762a@eastlink.ca> Date: Thu, 01 Feb 2018 07:52:21 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 In-reply-to: <13088.1517470216@thecus.kiddle.eu> Content-language: en-CA 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 >