Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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.

but

#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

2 Answers 2

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

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.