Why did 29fe7265b8 throw away the existing version of netcat? It seems that
netcat -f support is gone (instead you implemented your own minicom applet).
You can no longer get a server mode that listens to a dynamically allocated
port and tells you what the port number is, which is really useful for doing
things like:
qemu-system-ppc --nographic $LOTSOFARGS << EOF
#
netcat 10.0.2.2 $(netcat -l 127.0.0.1 tar c stuff) | tar xv
# Do stuff with copied files
tar c results | netcat 10.0.2.2 $(netcat -l 127.0.0.1 tar x)
EOF
I.E. you can pipe a tarball into qemu through the virtual network (bouncing off
the loopback device via the special 10.0.2.2 alias that connects to the host's
loopback interface), do work on the supplied files, and then send a tarball of
results back out.
In order for this to work, netcat has to A) announce the port number it's
working on (if it doesn't, dynamically allocating a "listen" port is
completely useless), B) daemonize itself so the $() doesn't block until netcat
exits, and thus never return to allow the result to be _used_.
The new netcat spits out debugging info for -v, which seems kind of useless
(it doesn't do B above at all, and you have to pipe it through sed to get
machine readable info out of the debug dump for A).
What was the advantage of throwing out the existing code here, exactly? (I
was thinking it might be a size issue, but although I haven't got 'em both
built to compare object sizes, the old one right before the change was 197
lines of code, the new one was 199 lines of code and did less.)
Rob
--
Latency is more important than throughput. It's that simple. - Linus Torvalds
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
