The premise is simple, you have a file on one computer that you want on a different computer on the same network and don't want a lot of fuss.
For the file you want to copy, on the machine where the file is located, run:
./bcp filename
Now go to the computer (on the same network) where you want the file to be at, and run:
./bcp
The file will be copied over the network and you're done.
I created it as a nice way of not having to worry about ssh or anything else really. In fact, it is so simple, I use it on my local machine a lot when hopping around between terminals instead of remembering paths.
I have tested it on OSX and Linux.
Suggestions and comments welcomed.
$ cat file | nc host.example.com 8888
I don't think a dedicated utility is required.
Edit: Sorry about my comment coming off as a bit hostile, I did not intend it to be.
But that's not the point here. Sometimes you just got to make something because you want to, because it fits a specific need that maybe not a lot of other people have, or because it's a learning experience, or just for the heck of it. So, no, it's not required, but that doesn't mean it's useless.
It's cool that the author did something productive that works for him/her, and it's even cooler they shared it with everyone.
I can say that's already infinitely more than what I made today. How about you?
char filename[MAXNAMELEN];
filename_size = 0;
memcpy(&filename_size, buf, sizeof(int));
memcpy(filename, &buf[sizeof(int)], filename_size);
I sympathize with the sentiment of "people should go out and try to create things themselves, even at the risk of failing" (or "especially" at the risk of failing), but from any objective standpoint, bcp isn't a good program. 400 lines of C to badly accomplish what 2 lines of shell can do? Someone else commented about it being very much in the unix spirit - no, I don't really think so. netcat + openssl would be in the unix spirit.
Not meant to be a criticism of the author - it's a cool project, if you don't care about certain "real-world" concerns (which isn't as unreasonable as it sounds).
I dont begrudge people reinventing the wheel, but i fully suspect this wouldn't have been written if the author knew about nc.
$ <file nc host.example.com 8888
Edit: Just to be clear, that'd be:
$ nc -l $port | gzip -d > $filename
$ cat $filename | gzip | nc $host $portIf you massage the discovery/rendezvous part in, it won't be nearly as simple as a single 'nc' command.
nc -l 8888 | tar xf - tar cf - file | nc host.example.com 8888
Also, unnecessary process spawned with cat: nc.host.example.com 8888 < file
bcp < filename
cat filename | gzip | bcp
bcp | gunzip > filename
Most (I won't say all) command-line apps must be explicitly told which mode to use. There's a good reason.
[0] http://pubs.opengroup.org/onlinepubs/007904875/functions/isa...
http://serverfault.com/questions/116875/how-can-i-disable-en...
Cipher - none.
So "ssh with no cipher" means "people can snoop, but I can use proper auth". But rsh means "plaintext pw - or worse things if allowed".
1) The code assumes both the client and the server have the same endian. This can be issue since a uint32 is used for both the synchronization code (BCP_CODE) and the port. This can easily fixed with htonl/ntohl conversions.
2) it assumes both the client and the server define int to be the same size (may or may not be true based on compiler/processor/OS combinations). If you use stdint definitions, this typically won't be an issue.
(Again, I don't mean to bash you or this project, just to say that it shouldn't be used in the "real-world" without being looked at rather more carefully. On a locally-secure network, or in an environment where security is unimportant, it's pretty cool.)
Can do this and other related useful things, including multicast of a file to N machines in parallel. Don't let the UDP bother you: it implements retry/checksum/etc on top of datagrams.
It's been around a few years, and is probably already in your distro.
It can pipe, as well as copy files, I wrote about it some time ago:
http://kylecordes.com/2008/multicast-your-db-backups-with-ud...
I've added a link for udpcast to my readme as an alternative. Thanks!
Though, this still looks more robust, thanks for the link.
Something like you just drag for the extreme left of right border, and sunddenly, the file is being transferred for the other computer.
The client-server arrangement is backwards though :) Typical arrangement is for the clients to do the "anyone there?" broadcast, for the servers to reply and then the client would select the server, connect to it and they would go about their business. In your case, the server connects to the client. If you re-arrange this to natural client-server order, you should be able to get rid of the fork() call and this will help with portability (not that you probably care at this point).
Also,
size = fread(&buf, 1, 100, ft)
Also, consider switching to multicast for discovery.
Good find on the fread, that is actually a "bug", should be MAXBUFLEN instead of 100.
Agreed on multicast, I will add that to do the todo.
Thanks for your feedback!
is another nice way to do this.
I actually use SimpleHTTPServer a lot for other things though, it is a great tip.
http://ipmsg.org/index.html.en (For Windows)
http://ishwt.net/en/software/ipmsg/ (For Mac)