No, I just put my terminal into a mode where I could see what I pasted without any possibility executing it. If you don't give cat any arguments, it reads from stdin and writes to stdout.

I could have just as easily opened vim/emacs/notepad and done the same, or for that matter, written the contents to an actual file instead of redirecting the contents to /dev/null.

But you could still paste ^d (End-of-file)? Granted, if you paste ^d in the terminal, you'd exit, but one could do this?:

  dangerous-commands \n
  ^d #eof
  dangerous-commmands \n #repeat

(I'm not actually sure if you can paste ^d in general... but I expect you could?)

Great point, we've just fired another salvo in an escalating war. The only winning move is not to paste. :)

My dentist won't let me do that :(

Cool, I've used cat for years and never realized it would do that if you don't have something actually piping to it. Totally makes sense now.

Like many Unix commands, if you don't give cat any files to read, it reads from stdin instead. So first he runs the command (as he typed it), and then while cat is waiting for input he pastes in whatever he copied from the website.

Another handy convention is the magic "-" filename (which is not actually a file). Many tools interpret that to mean stdin/stdout. For example here is a trick to copy a tree of files:

    tar cf - src | (cd dest && tar xvf -)

I'm glad I asked, I wasn't realizing that `cat` would read from stdin in this case. Makes sense, given the Unix piping philosophy (which I use to great effect on buffers in vim).

But wrt your trick to copy a tree of files, what's wrong with `cp -r src dest`, or `scp -r src desthostname:/dest` if it's over a network? Is there some advantage this way?

It's not quite the same as `cp -r`. Tar will create the directories if necessary, but it will also drop the files into an existing folder hierarchy. So you could use it to create/update a few entries in an existing tree of files. For instance you could deploy updates to a website like this (locally):

    cd ~/src/mysite && tar cf - . | (cd /var/www/public_html && tar xvf -)

or this (remotely):

    cd ~/src/mysite && tar czf - . | ssh mysite 'tar xvzf - -C /var/www/public_html'

I would probably actually use rsync for this, but there have been times the tar approach came in handy.

A long time ago, in the dark ages of version control, I used to use tar for rollback-able deployments: I would create a tarball of the files in development to be deployed, and I would create a tarball of the files in production to be overwritten. Then I could just explode one tarball to deploy and the other to rollback. Not something I'd do today, but we didn't always have such nice tools. :-)