5 ms·
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
by pjungwir 11y ago
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 -)
- jnbiche 11y agoI'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?
- pjungwir 11y agoIt'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. :-)