nc dies after reading port
 

I used: echo Hello > /dev/udp/127.0.0.1/12345
to test nc using: nc -ul -p 12345 in a different window (xfce)
nc will accept only 1 input and hangs; it does not terminate.
This is on Slackware 13.37 and the man page does not indicate that this is any standard procedure in fact to the contrary. I closed the echo command after sending the salutation but to no avail.
Any ideas why nc goes to sleep after the initial reading?

Moved: This thread is more suitable in Linux Software and has been moved accordingly to help your question get the exposure it deserves.

Using -p with -l is "in error" according to the man page for nc. Use "nc -ul 12345" to listen on port 12345

nc dies after reading port
 

Yeh - I've seen that referenced on the internet. Here is what my man page says:
nc -l -p port [-options] [hostname] [port]
This may be due to change in version, I'm not sure tho.

I have come across this also, and read the same pages by the sounds of it. I'm afraid I don't recall what I ended up using but I managed to have nc terminate after a successful message and that was it, but I am sure the man pages say it will go on listening indefinitely?

I used 127.0.0.1 localhost to test and after the first datagram that nc received it would not receive successive datagrams.

There is a netcat from netcat-openbsd package and another from a netcat-traditional package. That explains the -p differences, but not your question.

I think it has to do with the terminal or readline buffering rather than netcat. I may need to press ctrl-c after exiting from an ssh session.

I can verify that I see the same behaviour as you.

P.S. The listening terminal returns on killing nc. A sending nc doesn't return after
nc -u host 12345 < file