Interview With the Author of "Mastering Cat"

Shlomi Fish writes "O'Reilly is publishing a new book titled 'Mastering cat,' about the UNIX 'cat' command. Here is an interview O'Reilly-Net conducted with the author about it. Read it to see if this book should be part of your bookshelf of technical books."

Comments

Re:I tried mastering cat.

[verbalcontract]

But I kept on getting scratched...

Next time try piping to /dev/null.

Damn.

[castorvx]

I was hoping for a manual to help me read the icanhascheezburger comments.

Re:Damn.

[momerath2003]

That would be "lolcat," not cat. And here is a page to help you.

I just /usr/bin/cat my coffee everywhere.

[Mr. Flibble]

I guess I forgot what day it was, but the title article made me spew my coffee in laughter.

As an aside, remember kids, don't do this:

cat foo | grep bar

It is bad Unix! (If you don't know why, read the non-existent book on cat...) ;)

Re:I just /usr/bin/cat my coffee everywhere.

[steveha]

As an aside, remember kids, don't do this:

cat foo | grep bar

It is bad Unix!

Eh, it's not that big a deal.

Yes, you can simply say "grep bar foo" and it will have the same effect with less typing. But it's really not that big a deal, and there are times when I would do this. Usually it is because I'm doing something like this:

shell_script foo | grep bar

And I'm not getting the results I expect; then I might swap out the shell script part for cat, to help me debug. It's easier to type

cat !*

or even

^shell_script^cat

than to retype the whole command.

As long as you know what you are doing, build the command line any way you like. The computer exists to serve you, not the other way around...

Now someone will mod me (-1, No Sense of Humor) or (-1, Beating the Joke Into the Ground). But I regret nothing! Nothing, I tell you.

steveha

Re:I just /usr/bin/cat my coffee everywhere.

[TheRaven64]

The correct general way of doing it (which works for all values of grep) is:

$ grep bar < foo

You don't need to do this with grep, since it can take a file as input, but in the general case, any time you are using cat with a single file and a pipe you should be using <.

It doesn't make much difference when you are running a single command, but it makes a huge difference when you are running a loop or something like a find command. The extra cat doubles the number of fork() and read() system calls, adds a load of unnecessary write()s and adds a lot of copying that is otherwise unneeded.

But seriously

[Sloppy]

For example, one case where I found that people truly underestimate the power of cat is in the prefixing a line example. You can do that with:
echo "This would be the first line" | cat - myfile.txt > myfile.txt.new mv -f myfile.txt.new myfile.txt
But people do not realize that and instead opted to use sed, awk, or even perl (!).

I've done that.

Re:How about the followup?

[Sir_Lewk]

'tac' is an actual *nix program, prints files out in reverse.

Cat is useful. Really.

[Anonymous Coward]

These jokes are becoming lame, but cat is definitely one useful tool.

Well, I'm sure they can come up with an OReilly cookbook for cat. Cat is handy in a lot of situations. Consider these:

Concatenating the output of two PS files. Then you can merge two documents together into a single PDF.
Concatenating your .signature to an email message, useful in scripts.
Concatenating your self-extracting executable to its' data.
Using cat to pipe data into multiple filters all at once, without needing temporary disk space.

I wouldn't be surprised if there was such a book at all.

Re:How about the followup?

[palegray.net]

for getting [part of] a log file in reverse chronological order

Funny you should say that, it's exactly how I use the "tac" command.