Hacker News new | ask | show | jobs
by Udo 4878 days ago
There are a million ways to copy files, a lot of them are simpler to use than your example.

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?

3 comments

When the title says "Quickly copy a file..." it is reasonable to assume that we're talking about something quicker/easier then at least the most obvious ways to copy. But if we're talking about something you made just because you wanted to - it is more appropriate to present it as something like "Yet another way to copy a file..." - or, better yet, clearly state how your way is different from a million existing ways.
Don't forget also the "yet another HN karma or attaboy builder".

(Having spent years doing minor little things that nobody ever would care to hear about (back in the day) I can of course fully understand the positive aspects of the mental process. You learn something and perhaps people leave comments that make you feel good which spurs you on to do better things.)

Haha, that certainly is not the case. I made a tool, found it useful, a few of my other friends find it useful, so I posted it.

Some people voted it up, I can't control that. I really could care less about karma, in fact, the critical comments (except yours) have been very useful and worth the post.

I am just being part of a community.

I made it because with the nc solution, it still required knowing the hostname.

I now see though that ncp (http://www.fefe.de/ncp/) would have probably sufficed, though it is a slightly different approach.

Sorry if you feel mislead.

If you read the `nc` manpage, you'd notice that the -n option on osx and debian disables host lookup and that hostname is defined as

     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).
This solution is worse than the shell hack, by a lot. From the source:

    char filename[MAXNAMELEN];
and then a few lines down...

    filename_size = 0;
    memcpy(&filename_size, buf, sizeof(int));
    memcpy(filename, &buf[sizeof(int)], filename_size);
Oops! Looks like both the client and the server have to be trusted, otherwise we've got at least one probably-exploitable vulnerability. And there's no mechanism for authentication, so it's really only safe to use on locally-secured network. (That took about 40 seconds to find, by the way - I would not be particularly suprised if there were more subtly lurking issues.)

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).

The comments here remind me of the negative feedback Heather Arthur got when she dared to open-source some code: http://harthur.wordpress.com/2013/01/24/771/. The code is on Github. If you find a bug then why not fix it and send a pull-request instead of the negative public criticsm?
There's a difference between tossing some code on github and having random passersby poke fun at it, and submitting it yourself to HN.
It's a matter of opinion. For me projects (including this one) is news I prefer on HN
How do you do a pull request for "Use the pre-existing shell commands instead"?
Yeah, this is also on my list of todos.

I should have noted somewhere, this isn't ready for production by any means, just a first iteration of an idea I had. It is currently intended to be used on a trusted network.

Thanks for pointing this out though.

those hours of time spent writing the code could have been saved by spending minutes learning the standard way of doing it (and given the ubiquity of nc, its utility would stretch far beyond this use case)

I dont begrudge people reinventing the wheel, but i fully suspect this wouldn't have been written if the author knew about nc.

It wasn't many hours and I know nc and have used it this exactly way. However, nc requires you know the hostname, an assumption I didn't want to make.

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.

If you read the `nc` manpage, you'd notice that the -n option on osx and debian disables host lookup and that hostname is defined as

     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).
You still need to know the IP. I use nc this exact same way, and it's definitely a hassle -- not a big one, but still -- to have to check ifconfig on one of the machines and then re-input the IP on the other. On internal networks where IPs are assigned by DHCP on connection and can and do change frequently this essentially needs to be done every time you send a file.

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.

nc does this with the broadcast addresses (read https://en.wikipedia.org/wiki/Broadcast_address for more info):

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 6969
1. In general, I am on the computer I want to send from, then I go to the computer I want to receive on. This script seems to require I be at the receiving computer first. Is there a trick to do it my way?

2. 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.