When faced with the task of finding something in "ps", old Unix hands will almost automatically type "ps -e | grep" and follow that with whatever they are looking for. I can tell you that after so many years of doing that, it's almost reflexive. We may know that there are other ways, but it's the old saying: walk too close to a habit and it will bite you.
The good thing is that most of the time that habit just wags its tail and gives us what we want. Even when there
is a playful little snap of the teeth accompanying the tail wagging, we're often doing that at the command line and can ignore any superfluous output. It's when our grepping is buried in a script that the results may turn tragic.
There are a LOT of things that can go wrong with "ps -e | grep". I'll try to cover the most damaging things, but
I might miss one or two. If you take away nothing else from what follows, make it this: test scripts carefully and do not assume anything!
There are other ways to get processes matching some string. For example, on Linux:
X=`ps -e | grep $1`
# -ec on Mac
Nothing wrong with that, right? Look, it works:
$ ./t.sh vim
1474 ttys001 0:00.00 /bin/bash ./t.sh vim 1475 ttys001 0:00.00 /bin/bash
./t.sh vim 1477 ttys001 0:00.00 grep vim 1462 ttys002 0:00.01 vim foops
OK, what about this?
$ ./t.sh taskgated
1480 aa ab bh dl ds dt ex me pj pt re sc t1 t2 tp tt xt zz 0:00.01 taskgated
What's all that "aa ab bh" stuff? Here, let's see if this helps:
$ ls ??
aa bh ds ex pj re t1 tp xt
ab dl dt me pt sc t2 tt zz
You have to be careful with pulling in the output of "ps" and randomly echoing it. The "ps" lines for daemons will include a "?" in the controlling tty column, so if you did "x=`ps -e | grep whatever`", the returning line would have a "?" (on Mac OS X, two "??"). If your script then does "echo $x", the ? mark or marks will match one or two character file names that happen to be present in your current directory. As this is directory dependent, your script might appear to work correctly initially and then break later.