6 ms·

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

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

niggler 14y ago
Better to do $ <file nc host.example.com 8888 (performance benefits more apparent with larger files)
- HorizonXP 14y ago
  Care to explain why?
  - niggler 14y ago
    (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)
    - blibble 14y ago
      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...
      - 1337p337 14y ago
        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
Udo 14y 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?
- niggler 14y ago
  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.
  - diginux 14y ago
    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.
    - niggler 14y ago
      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).
      - entropy_ 14y ago
        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.
sigjuice 14y ago
Here is your award :p http://partmaps.org/era/unix/award.html#cat http://partmaps.org/era/unix/award.html#cat
deleted 14y ago
[deleted]
huhtenberg 14y ago
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.
Dylan16807 14y ago
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.
diginux 14y ago
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.
lucb1e 14y ago
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
luppolo 14y ago
>Sorry about my comment coming off as a bit hostile, I did not intend it to be. LOL fukk off... wat a poossy -_-
meaty 14y ago
+1 I've been doing this for years for nefarious purposes :)
randomracker 14y ago
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

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

niggler 14y ago

Better to do $ <file nc host.example.com 8888 (performance benefits more apparent with larger files)

HorizonXP 14y ago
Care to explain why?
- niggler 14y ago
  (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)
  - blibble 14y ago
    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...
    - 1337p337 14y ago
      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

Udo 14y 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?

niggler 14y ago
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.
- diginux 14y ago
  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.
  - niggler 14y ago
    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).
    - entropy_ 14y ago
      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.

sigjuice 14y ago

Here is your award :p http://partmaps.org/era/unix/award.html#cat http://partmaps.org/era/unix/award.html#cat

deleted 14y ago

[deleted]

huhtenberg 14y ago

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.

Dylan16807 14y ago

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.

diginux 14y ago

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.

lucb1e 14y ago

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

luppolo 14y ago

>Sorry about my comment coming off as a bit hostile, I did not intend it to be. LOL fukk off... wat a poossy -_-

meaty 14y ago

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

randomracker 14y ago

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