Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.
Sign up to join this community
See original Q&A about grep not accepting netcat output on stderr at a prior StackExchange post.
Concise answer. I like it. Why does adding a tee on the end fail to produce any output?
nc -zvv localhost 3100-3200 2>&1 | grep succeeded | tee test.txt
Using only tee works. Using only grep works. Chaining tee after grep gives no output (console or file).
Any ideas?
DevilaN, Kusalananda,
Thank you. It was a combination of my impatience and grep and nc behavior. Using the command below on my Raspberry Pi,
nc -nvw1 127.0.0.1 1-65535 2>&1 | grep succeeded | tee test.txt
All the ports were scanned, ~then~ the console printed out 6 open ports. When I used the --line-buffered option, the command behaved as I expected (printing as they were found).
Also, the buffering behavior of grep apparently happens only when piped into tee. When tee is not used and the --line-buffered is not used, grep still prints out the open ports as found.
Without the -w1 option, the first open port is printed on the console by grep, but then the output hangs - actually it's the output of nc that hangs in this case.
grep buffers as soon as its output is not written to a terminal. The fact that it is tee after the pipe is irrelevant, it's the fact that the output is piped that matters.
localhost [127.0.0.1] 22 (ssh) open localhost [127.0.0.1] 21 (ftp) : Connection refused, and you seems to expect "succeeded"grepwill not output anything until 1) its output buffer is full, or 2)ncterminates. The issue is with buffering, and you can turn this off by usinggrep --line-buffered(withgrepimplementations that support this non-standard option). The buffering is there for performance reasons, and happens when the output ofgrepis not a terminal (it's a pipe in the example in the question).ncis running with example command from OP in under 1 second, so I thought that waiting for buffer is no issue in this case.ncis connecting to when the user in the question is using that command? I.e. what's running on the specified ports? We can assume that it is not responding withConnection refused, because the user says that there is no output.nc -zvvis not waiting for any service output but only connects to find out whether there is port open. To think of now, there might be some app, that is not doingaccept()right away and this might be a reason for long scan, but this seems to be very unusual situation (but not impossible).