Shell gurus! A question....

Shell gurus! A question....

Post by David Douthit » Fri, 08 Jun 2001 00:44:08



I'm trying to write something in semiportable sh/ksh (to run under
bash and ash).  Basically this works:

tail -f | egrep "$PAT" 2> /dev/null

...but THIS outputs NOTHING....

tail -f $LOG | egrep "$PAT" 2> /dev/null | some_other_command

...in place of "some_other_command" I've tried the following:

cat
cat -
xargs echo
while read LINE ; do .... done (loop - in a function)

...what I would *REALLY* like is some sort of:

eval $ACTION &

...where ACTION is some command which processes the output, one line
at a time - like paging or sending Windows popup alert boxes.  What am
I missing???

 
 
 

Shell gurus! A question....

Post by Steve Kirkendal » Fri, 08 Jun 2001 02:27:55



> I'm trying to write something in semiportable sh/ksh (to run under
> bash and ash).  Basically this works:

> tail -f | egrep "$PAT" 2> /dev/null

> ...but THIS outputs NOTHING....

> tail -f $LOG | egrep "$PAT" 2> /dev/null | some_other_command

I suspect that "egrep" is buffering its output.  By default, the
C standard library performs line buffering if stdout is a terminal,
and block buffering otherwise. If you waited for enough lines to be
matched (4K bytes' worth?) then you'd probably see some output.

Surprisingly, "egrep" does not appear to have a flag for disabling
its output buffering.  (For the "tail" program, the "-f" flag has
the side-effect of disabling its stdout buffer; that's why the first
pipe isn't causing any problems for you.)

If I'm right about this, then one way around this problem would be
to invoke "egrep" separately for each line emitted by "tail":

    tail -f "$LOG" | while read line
    do echo "$line" | egrep "$PAT" 2>/dev/null
    done | some_other_command

 
 
 

Shell gurus! A question....

Post by David Douthit » Fri, 08 Jun 2001 04:00:43




> > I'm trying to write something in semiportable sh/ksh (to run under
> > bash and ash).  Basically this works:

> > tail -f | egrep "$PAT" 2> /dev/null

> > ...but THIS outputs NOTHING....

> > tail -f $LOG | egrep "$PAT" 2> /dev/null | some_other_command

> I suspect that "egrep" is buffering its output.  By default, the
> C standard library performs line buffering if stdout is a terminal,
> and block buffering otherwise. If you waited for enough lines to be
> matched (4K bytes' worth?) then you'd probably see some output.

> Surprisingly, "egrep" does not appear to have a flag for disabling
> its output buffering.  (For the "tail" program, the "-f" flag has
> the side-effect of disabling its stdout buffer; that's why the first
> pipe isn't causing any problems for you.)

> If I'm right about this, then one way around this problem would be
> to invoke "egrep" separately for each line emitted by "tail":

>     tail -f "$LOG" | while read line
>     do echo "$line" | egrep "$PAT" 2>/dev/null
>     done | some_other_command

Thank you!  That was just the thing!

I had thought of buffering, but my first thought was to use stty raw
or stty cooked but I don't understand them enough to make it happen,
and this is MUCH better.

 
 
 

1. AN INTERESTING QUESTION FOR SHELL SCRIPT GURUS


No shell specifics to this; should run happily under sh, ksh, bash. csh I
wot not.

The /dev/null is a trick to make "grep" echo the name of the file as a
prefix to each line that matches. A quirk of "*grep" is that, with less
than two inputs, it merely echoes the matching lines; with two or more
inputs, it echoes <filename>:<matching line>. Of course, nothing ever
matches in /dev/null, but you've satisfied the "more than one file"
requirement.
Cheep trik.

--

    Engineers think equations approximate reality.
    Physicists think reality approximates the equations.
    Mathematicians never make the connection.

2. Help with NFS

3. Shell gurus! A question....

4. max root partition size for Solaris 8

5. AN INTERESTING QUESTION FOR SHELL SCRIPT GURUS

6. linux as a gateway

7. USB problem

8. A SIMPLE QUESTION FOR SHELL SCRIPT GURUS

9. Shell script guru wanted

10. Shell guru help me !!

11. Thanks to the Shell scripting GURU'S

12. JOB: northern NJ, UNIX guru, shell programming, fortune 50 company