[Top][All Lists]

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

Re: IMPLEMENTATION [Re: Hightlighting in bash]

From: Philip Prindeville
Subject: Re: IMPLEMENTATION [Re: Hightlighting in bash]
Date: Thu, 10 Mar 2011 14:03:09 -0800
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv: Gecko/20101207 Thunderbird/3.1.7

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>.

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
<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
   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 


reply via email to

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