Several people in this thread have indicated that they have wasted hours
if not days to track down seemingly random failures.
The Ubuntu manpage guarantees this to work:
echo -n "GET / HTTP/1.0\r\n\r\n" | nc host.example.com 80
The original OpenBSD nc does not even have the -q option:
http:
Soren,
netcat in the most recent Fedora does not have this behavior.
"If you depend on a specific behaviour, you should be specifically asking for
said behaviour rather than relying on default values."
ISTM that this advice is meant for libvirt. - Seriously, this does not apply
when
every nc
Soren,
thank you for considering the issue. However, I still think this is a
bug:
1) The program is called nc.openbsd and nc on OpenBSD does not
have this behavior.
2) I'm not aware of any other nc that has this behavior. One would also
not ship an echo where -n is the default.
Confirmed on Intrepid. nc.traditional is not affected.
It would be _very_ nice to give this bug a high priority. I spent several hours
searching for bugs in Twisted and asyncore.py because I simply did not
expect a broken netcat.
--
netcat-openbsd stdout broken on Ubuntu
https://bugs.launchpad.