I'm not the maintainer, but use netcat a lot. Here are some comments: On Saturday 14 May 2005 10:55, Dr. David Alan Gilbert wrote: > I'm trying to shovel a large amount of data (800GB) between two > machines, so have a pair of tar's running over netcat as follows: > > on the source: > > tar -clf- . | nc destination 6666
First of all, did only one, or both of these commands actually result in a message from your shell telling you it was waiting for stdin? It really makes a difference: If this one was looking for input, it would have had to have been tat, not netcat, as netcat's stdin is tied to tar's stdout, so it couldn't have blocked the shell; only tar could have. Did this one say that the program was waiting for input, or was it just the other one below? > on the destination: > > nc -l -p 6666 | tar -xpf - > > I had these running in a background'ed nohup and after a while the > copying stopped and bash told me that the backgrounded destination > package had stopped waiting for input; sure enough I 'fg'd > it and hit return a few times and it carried on its way. I'm not sure why netcat would be blocking on input here (it only does non-blocking reads in it's main I/O function (readwrite), but if this happened to you on this command line, that is where the bug mostly like lives. =) There is an easy workaround for either case (bug or not), though: when you run that command, you're leaving netcat's stdio hooked to your terminal. I'd suggest tying it's stdin off to /dev/null, with something like: $ nc -l -p 6666 < /dev/null | tar -xpf - (You could run the tar command similarly if it was giving you trouble:) $ tar -clf- . < /dev/null | nc destination 6666 -- Wesley J. Landaker <[EMAIL PROTECTED]> OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2
pgpV0mnIs3Luk.pgp
Description: PGP signature
