Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm trying to grep the output of ngrep. Unfortunately when I add another grep to the pipeline, I get no output at all. It can be some other command too - cat / grep / tee - everything breaks the chain. Example:

# this works:
$ ngrep -l -q -T -Wbyline -d any udp and port 5060 |
    egrep -B1 '^SIP/2.0 180'
U +1.469535 xxx:5060 -> xxx:5060
SIP/2.0 180 Ringing.
U +0.001384 xxx:5060 -> xxx:2048
SIP/2.0 180 Ringing.


#these don't:
$ ngrep -l -q -T -Wbyline -d any udp and port 5060 |
    egrep -B1 '^SIP/2.0 180' | egrep '^U'
$ ngrep -l -q -T -Wbyline -d any udp and port 5060 |
    egrep -B1 '^SIP/2.0 180' | cat
$ ngrep -l -q -T -Wbyline -d any udp and port 5060 |
    egrep -B1 '^SIP/2.0 180' | tee test

If I use cat somefile instead of ngrep at the start, everything works as expected. Any ideas what could go wrong here?

share|improve this question
What happens if you omit the -l parameter from ngrep? – jdigital Feb 6 '10 at 0:16
Same - no output after the second pipe. – viraptor Feb 6 '10 at 1:46
up vote 2 down vote accepted

Have you got egrep aliased to anything that might modify the text, like grep --color might do? $ type egrep

Also check the output for "hidden" control characters using od -bc (as jch mentioned) or hd -C.

share|improve this answer

EDIT: I just ran into this myself with 'egrep' - was doing:

tail -f somefile|egrep 'somepattern'

Which would provide gratifying output every two seconds; but the following produced nothing:

tail -f somefile|egrep 'somepattern'|tr -d '%'

After some digging in the man page I found the '--line-buffered' option which produced output again!

Then I found this description of buffering in pipelines - it looks like what it boils down to is that some command line utils (eg: tail -f) routinely call fflush on stdout and others (cut, grep, etc) do not.

My wrong first reply is below

Usually when I run into these types of issues, one or more of the programs in the pipeline are putting output on multiple file descriptors - most often STDERR.

You might try adding '2>&1' before your first '|' in the pipeline to redirect STDERR to STDOUT.

share|improve this answer
The first grep already handles the ngrep output, so everything goes through stdout path. – viraptor Feb 5 '10 at 21:00
ok - it's possible that some non-printing characters are coming in the output stream what do you get when you do: $ ngrep -l -q -T -Wbyline -d any udp and port 5060 | egrep -B1 '^SIP/2.0 180' | head -4 | od -bc – jch Feb 9 '10 at 16:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .