I just wasted a full, extremely frustrating working day trying to find
why a complicated script involving in-house software and a tangle of
named pipes and background commands stopped working. Now it's after
midnight, I'm still at work, and I found out it's this. I'm right now
very tempted to give up on ubuntu.
Even worse, the -q workaround doesn't work for me; I had -q in my scripts all
the time just for good measure. My server-side application is a sponge. Like
the unix "sort" command, it first soaks up all the input, and only after it
receives and EOF through the input channel, it processes the input and starts
producing output. Traditional netcat behavior with -q x would be (from the
client-side point of view):
- upon receipt of an EOF on stdin, close the output stream, putting the TCP
connection in half-close state (this effectively transmits the EOF to the
server, triggering my server-side application to start processing)
- wait x seconds (while data from the server-side application flows in)
- quit (in my case, it actually quits before the x seconds are over because the
server closes its side of connection when it finishes processing)
Ubuntu's new borken netcat does the following instead:
- receive an EOF on stdin but don't let the remote host know (I speculate this
is a "feature" of BSD netcat but it might also be another ubuntu bug)
- wait x seconds
- quit (only now an EOF is detected at the server side, but it's too late to
send data back)
As you can see, my scripts are now broken beyond repair. My only
solution is installing netcat-traditional.
One of the great features of the traditional netcat was that it could function
as a two-way unix pipe for TCP (hint: net-cat). Swallowing the EOF breaks this,
as illustrated by the above example. I don't know what people were thinking
when they changed this, but they surely haven't been reading the traditional
netcat man page:
You may be asking "why not just use telnet to connect to arbitrary
ports?" Valid question, and
here are some reasons. Telnet has the "standard input EOF" problem, so
one must introduce
calculated delays in driving scripts to allow network output to finish.
This is the main rea-
son netcat stays running until the *network* side closes.
Further discussions about this issue:
http://oskt.secure-endpoints.com/man/knc.1.pdf
http://www.eggheadcafe.com/software/aspnet/36139087/example-code-for-using-gawks--operators.aspx
nc6 seems to have the best solution: by default, it works like the "BSD-style"
netcat, but it has the --half-close flag which makes it work like traditional
netcat (and saves the day for me).
http://linux.die.net/man/1/nc6
--
netcat-openbsd exits too soon
https://bugs.launchpad.net/bugs/544935
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
