back
32 comments
Not sure if I should share this, but here it goes.

One nice trick I used a lot when in college is that some postscript network printers would print raw postscript sent to them on a specific port (which I can't remember sorry). This allowed me to use netcat toprint my documents bypassing the college's print quota system and everyone who would be waiting in the queue.

Usually it's port 9100. Bash (and for sure also tcsh or zsh, not to start any flamewar) has a nice builtin tcp-socket interface by redirecting to the "pseudo" tcp device, so you don't even need nc for it on most current unices.

cat file.ps >/dev/tcp/10.2.3.4/9100

Wow, I had no idea about the bash device. This is great.
Note that it's disabled in Debian because the package maintainer has some stupid notion that it's a security hole.
Which is epically obnoxious when you have an open shell on a dying remote box that's lost /lib/libc.so.6 and you're scrounging for a way to restore it. I was halfway through writing a uudecode implementation using only bash builtins when the hosting company got me a serial line on the box.

I despise their policy of diddling with every upstream package -- disabling default build options, removing config files, separating the peas from the carrots, splitting pieces off into new packages, and all that anal-retentive bullshit. It's much worse on systems where there are fewer people keeping an eye on the maintainers -- ever try to use fink?

Well, Debian is the worst-maintained distribution out there, except for all the other ones.
That's just the problem -- they do massively more maintenance than any other software project ever to exist.

They waste nearly all of their effort doing the fussiest of tasks. The root issue is the pointless 'version' freezes -- they end up forking every single upstream project, being careful to never backport features (only 'bugfixes', which are never really so when isolated from context), and aim for a zealous consistency in the wholesale removal of any features which conflict with their ideology.

I used to get pissed off when the Debian people quoted astronomical figures about how many LoC are 'in Debian', but I got over it -- they really do wear the hair shirt.

Also works for PCL to HP printers - If you're on a windows network you can simply open the printer "//server/xyz" and send the PCL through.

Many years ago I used this to print documents from a Java backend (which didn't support printing without a GUI+Print Dialog)... Manually generated the PCL. Bit of a hack, but did the trick.

This is definitely worth sharing. The IT department and the computer lab guys are worse than the Soviets. They keep all these strict quotas, you have to wait in line for anything to get done, and the applications they run are old (unless they're Microsoft or Adobe applications).
When I was in a PC support position, there weren't any quotas; we just had a print server because it was much easier to organize and configure that way. Anyone wanting to set up a printer directly was more than welcome to, so long as they didn't fuck it up and then come crying to me when it didn't work.

You can do this in windows by setting up a TCP printer rather than connecting to a print server.

I recommend the even more capable Ncat (http://nmap.org/ncat/), which is a reimplementation of netcat by "The Nmap Project".
I recommend checking out socat (http://www.dest-unreach.org/socat/) as well.
I recommend checking out lolcat, too (http://en.wikipedia.org/wiki/Lolcat).
I actually thought you were recommending a piece of software that had a punny name...
Indeed. I threw together this dead simple HTTP server written in shell + netcat the other day, for debugging some CGI scripts:

http://github.com/tlrobinson/wwwoosh/blob/master/wwwoosh.sh

(only handles CGI scripts at the moment, could be modified to serve files, etc)

Nice, that's really cool :)
netcat + ssh's -R and -L = unstoppable

ssh -D is also awesome for when you need a quick http tunnel.

Another trick I picked up is basically:

  nc -l [port] | named_pipe | nc [other_host] [port]
That will tunnel things between two netcat instances, effectively setting up a tunnel. Replace 'named_pipe' with a shell and you have a quick and dirty remote shell.
Can you explain this further. There are three machines A,B,C A can connect to B and B can connect to C but A cannot connect to C How can netcat/ssh be used to forward a port on B such that when A connects to that it connects to C [on a specific port]. basically B acts as a proxy.
This is from memory so take it with a grain of salt:

2048 is the port you're forwarding.

Machine B:

  machine_b$ mkfifo /tmp/tunn
  machine_b$ nc -k -l 2048 < /tmp/tunn | nc [machine_c] 2048 > /tmp/tunn &
You should now have a working tunnel. Everything sent to B on 2048 will be sent to C:2048
Then just wait until you discover ngrep! ;-)
NC allows good quick hacks but beware that it could open security issues as well. e.g. never do "nc -l -p 1234 -e /bin/bash" beyond your local machines.
I discovered some awesome in Netcat while playing with BashReduce (http://github.com/erikfrey/bashreduce/).

That said BashReduce uses the Debian version of Netcat which is different from every other version I could find. I ended up running Debian in VMWare to get BashReduce up and running on my Mac.

I like using netcat together with dd for cloning hard disks or volumes over a network. Great for cloning laptops, especially out and about, where it's often nontrivial to attach both drives to the same system simultaneously. Inserting gzip/gunzip into the pipe helps over slow connections.
Last.fm has a pretty nifty notification system that uses netcat and an IRC bot. http://www.metabrew.com/article/how-we-use-irc-at-lastfm/
One of my favorites for quickly copying a directory between hosts is...

dsthost# nc -l 1234 | tar -xvzf - -C .

srchost# tar -xzf - . | nc dsthost 1234

Heh, I used to use rsh (or was it rlogin?) for the same purpose back in the day, before rsync came along.
and we used to use ttcp (for it was more efficient with slinging around large files.)
In most of those examples, you'd use telnet or scp or nmap.
nmap is a little heavyweight at times, it's the swiss army knife, while netcat is more like a simple blade.

Sometimes it's meaningful to avoid telnet because of the terminal negotiation it does. Other times, telnet is useful because it can do line buffered input, allowing line edits (I often mistype the protocol version string when testing HTTP directly).

yes that is the point. power == doing what would take 3 other programs to do.
, poorly.