Without thinking too hard, I thought that was what the listener/server-end netcat was supposed to do ... quit when the connection to it dies ...
One connection or both connections? Because netcat always uses two...
Well, you might be using netcat for something I've not. The listener end of netcat will shut down when the client end closes the port, this is a given ... however, the client end does not by default close the port when it's stdin reaches EOF ...
From "man nc"
Your standard input is then sent
to the host, and anything that comes back across the connection is sent
to your standard output. This continues indefinitely, until the net-
work side of the connection shuts down. Note that this behavior is
different from most other applications which shut everything down and
exit after an end-of-file on the standard input.
What do you mean, netcat always uses two connections? There's stdin and stdout, for sure, but only one network connection ... perhaps I'm thinking at a lower level than you are.
Dito for the client - perhaps the client doesn't want to send anything (</dev/null) and only receive - you can't do that currently, as the client buggers off faster than you can look.
OK, an example must be needed ... I'll start a listener that sends data (rather like a mail server sends out an identification message when you connect), and then connect to it ... Two sessions, A and B ...
A$ echo "Hello" | nc -l -p 7777 > /tmp/reply
B$ nc localhost 7777 Hello
after a couple of seconds to absorb the importance of the word "Hello", I'll type into stdin of B's netcat ...
Greetings ^D
B's netcat doesn't quit, even though I've sent EOF. A's netcat doesn't quit, either. /tmp/reply has been populated though, and I can see its contents from another session ...
$ od -a /tmp/reply 0000000 G r e e t i n g s nl 0000012
I can put more stuff into B's netcat, and finally get fed up and terminate it with ^C ... at which point A's netcat listener terminates.
The contents of /tmp/reply haven't changed, though, because the shell redirection has been 'completed' when the EOF at the end of "Greetings" was sent.
If I didn't redirect the netcat listener's stdout, there would still be a stop on output when the EOF came through ... this is what you would see from the shell sesion ...
A$ echo "hello" | nc -l -p 7777 Greetings A$
(I've made my ^D characters visible below :- B$ nc localhost 7777 hello Greetings ^D More Stuff ^D B$
I think I'll need to see an example of your usage that you're having difficult with ... :-)
-jim
