Here's a wonderfully easy mistake that you can make using grep:
grep -r whatever . > output.file
For those that don't know this command, here's what's going on:
So what this command says is "look in all files in this directory and its subdirectories for the string "whatever" and write any lines you find to output.file."
Do you see the error? Neither did I, the first time I typed this in, hit enter, and waited. and waited. and waited.
Eventually, I hit ctrl-c, took a look at the output file, and began to laugh. (I wasn't sure who I was laughing at -- myself, or the person that wrote the command.) The problem was, I told grep to look in every file in the directory. I never told it not to look into the file it was creating. So it was merrily churning along, reading its own output file, finding the search string on every line (of course), and appending new lines on to the end.
This is a classic mistake -- failure to remember that the computer is just a very fast idiot.
If you're wondering how to avoid this problem, here are two solutions. The explanation of why they work is left as an exercise.
grep -r whatever . > ../output.file
grep -r whatever . | cat > output.file
Disclaimer
I did this using Cygwin under Windows NT. I do not know that it would behave the same way under other Unices, although I suspect it would. Also, while preparing this writeup, I made sure I could re-create this behavior, and found that it only occurs if there is at least one hit in a subdirectory. Somebody ambitious could read the source code and explain why this happens.