Hacker News Reader

Hacker News

Comment by midnightsine | Hacker News Reader

Full thread

midnightsine

$ nc -l 8888 > file

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

View on HN

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?

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

    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.

To solve both complaints, just tar -c on the ingress and tar -x on the egress:

    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)

Doesn't seem to work for me

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

I'm not at a terminal now so can't verify this but it looks like you swapped the send and receive addresses from what was suggested. Try send on broadcast and receive on 0.0.0.0.

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

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.

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"?

Here is your award :p

http://partmaps.org/era/unix/award.html#cat

Better to do

    $ <file nc host.example.com 8888

(performance benefits more apparent with larger files)

Care to explain why?

(you can find more info in the manpage for your shell)

    $ cat foo | bar

ends up creating two processes and a pipe. The foo file is first read by cat and then written onto the pipe (which bar then reads).

    $ <foo bar

is an input redirection: foo is opened for reading and bar's standard input fd is set to that open file (so the file's data is only read once)

for reading files and transferring over the network: the limit is always going to be the IO devices, not an extra context switch and a few extra copies...

s/always/usually/. Depending on the disks involved and your network hardware (either a super-fast link, or even a system with a slow CPU and cheap network hardware that expects the drivers to do the heavy lifting in software), it actually could end up CPU-constrained.

But for the usual case where it is I/O-constrained, you can often get files across more quickly by throwing CPU at reducing the total amount of bandwidth required by, e.g., using something like bzip or pbzip:

  pbzip2 < file | nc $host $port

And on the other side:

  nc -l $port | pbzip2 -d > file

I'd pipe it through gzip, but yes that's exactly what I was about to reply.

Edit: Just to be clear, that'd be:

    $ nc -l $port | gzip -d > $filename
    $ cat $filename | gzip | nc $host $port

This requires you know the IP/domain of the host. With DHCP on my laptop, this is not always the case. Yes, I know how to lookup my ip, but doing it every time becomes a pain.

Still need to get host.example.com from somewhere.

If you massage the discovery/rendezvous part in, it won't be nearly as simple as a single 'nc' command.

Bleh. I want to copy then paste, not create a pasting port then point a copy at it. And it's twice as much typing, too.

avoid retyping the file name:

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

+1 I've been doing this for years for nefarious purposes :)

Reply on news.ycombinator.com