I appreciate the criticism though, it is always good to question the investment of time. In this case, I feel comfortable with it. Can't discount the joy of programming little things either.
I appreciate the criticism though, it is always good to question the investment of time. In this case, I feel comfortable with it. Can't discount the joy of programming little things either.
hostname can be a numerical IP address or a symbolic hostname (unless the
-n option is given). In general, a hostname must be specified, unless
the -l option is given (in which case the local host is used).I'm not saying that it's such a big hassle that we need complicated ways of avoiding it, but this is definitely a cool project that does a away with a (minor) pain point and I for one applaud the author for scratching his itches and sharing with the world, even if his hack isn't perfect.
Recipient listens on 0.0.0.0:
recipient$ nc -l 0.0.0.0 6969 > file
Sender broadcasts to broadcast address: sender$ <file | nc 192.168.0.255 6969
or sender$ <file | nc 255.255.255.255 69692. A very minor point, but you are still required to know (or at least specify) a the filename on the receiving end. My solution does not.
sender$ tar -c file | nc -l 12345
recipient$ nc addr 12345 | tar -x
This will create a file on the recipient side with the specified name and properties (and you run the sender command first)sender$ tar -c awesome.jpg | nc -l 0.0.0.0 12345
(waiting forever)
recipient$ nc 255.255.255.255 12345 | tar -x
tar: This does not look like a tar archive
tar: Exiting with failure status due to previous errors