[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IMPLEMENTATION [Re: Hightlighting in bash]

From: Chet Ramey
Subject: Re: IMPLEMENTATION [Re: Hightlighting in bash]
Date: Thu, 10 Mar 2011 17:10:16 -0500
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: Gecko/20101207 Thunderbird/3.1.7

On 3/10/11 5:03 PM, Philip Prindeville wrote:
> On 3/10/11 12:50 PM, Micah Cowan wrote:
>> (03/10/2011 12:28 PM), Micah Cowan wrote:
>>> (03/10/2011 11:53 AM), Micah Cowan wrote:
>>>> (03/10/2011 11:42 AM), Philip Prindeville wrote:
>>>>> My request is simple.  Using termcap/ncurses info (which you need anyway
>>>>> for the readline stuff), it would be nice to have the option of running
>>>>> commands in a pseudo-tty and then bracketing the output from STDERR with
>>>>> <highlight on>...<highlight off>.
>>> <snip>
>>>> It wouldn't be difficult to write as a separate program, which is really
>>>> how this should be handled. You could redirect a pipeline's STDOUT and
>>>> STDERR to individual named pipes (FIFOs), and have a separate program
>>>> read from both pipes, inserting highlights around any data it copies
>>>> from the STDERR pipe.
>>> The idea intrigued me somewhat, so I hacked up a Perl script that
>>> attempts to do this (no guarantees of error-free code).
>>> Find it at http://micah.cowan.name/hg/demarcate/raw-file/tip/demarcate
>>> Set it to executable, and then try it out like:
>>> mkfifo out
>>> mkfifo err
>>> ./demarcate
>>> <some program>   >out 2>err
>> Note that you can also just do:
>>    exec>out 2>err
>> instead of running a specific program under it; but note that
>>    1. this works somewhat poorly if your prompt is colorized, or clears
>>       graphical attributes
>>    2. your prompt will now be highlighted, since readline emits it to
>>       stderr.
>>    3. bash can apparently do line-editing this way; ksh93 seems to have
>>       a problem doing so.
>> Basically, I don't recommend this, but it can work for some needs.
>> (Idea for improving this program: allow for giving a shell command as an
>> argument, eliminating the need for silly named pipes; just have the
>> script redirect the specified command through normal pipes.)
> A lot of programs don't behave properly (or perhaps, "don't behave the
> same") when they detect that stdout isn't a terminal.  But I think someone
> else mentioned this already.

That's why I suggested adapting a pty program for this.

``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    address@hidden    http://cnswww.cns.cwru.edu/~chet/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]