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?
localhost [127.0.0.1] 22 (ssh) open localhost [127.0.0.1] 21 (ftp) : Connection refused
, and you seems to expect "succeeded"grep
will not output anything until 1) its output buffer is full, or 2)nc
terminates. The issue is with buffering, and you can turn this off by usinggrep --line-buffered
(withgrep
implementations that support this non-standard option). The buffering is there for performance reasons, and happens when the output ofgrep
is not a terminal (it's a pipe in the example in the question).nc
is running with example command from OP in under 1 second, so I thought that waiting for buffer is no issue in this case.nc
is 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 -zvv
is 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).