gistfile1.mkd

Trick The First: filtering ps

So you know how ps piped to grep shows you the grep command?

$ ps auxww | grep bash
ben      64291   0.0  0.0  2435036    372 s001  R+   11:48AM   0:00.00 grep bash
ben      61887   0.0  0.0  2435468   1896 s001  S    11:38AM   0:00.13 -bash
ben      61376   0.0  0.0  2435468   1888 s000  S+   10:46AM   0:00.06 -bash

I don't understand why, but if you wrap the first character of your grep in a character class, that doesn't happen:

$ ps auxww | grep [b]ash
ben      61887   0.2  0.0  2435468   1892 s001  S    11:38AM   0:00.14 -bash
ben      61376   0.0  0.0  2435468   1888 s000  S+   10:46AM   0:00.06 -bash

Trick The Second: Oops, I forgot my &&

Sometimes you start a long-running process:

$ ./something_long

...and then realize that you want something else to happen after it, as though you had done:

$ ./something_long && ./something_else

...but of course you forgot to do that at first. Try this on for size:

$ sleep 30
^Z
[1]+  Stopped                 sleep 30
$ fg && echo "done"
sleep 30
done

The regular expression (the b inside the square brackets) matches a character set which contains a single character (lower case b in this case) and the literal string "ash." So this grep can't self-match the original regular expression string, as it also includes the square bracket

Oh jeez, of course. It's kind of blindingly obvious once someone points out that the square bracket is there in the ps output... I just always read past it blindly.

This is why I use pgrep (-lf) where available.

The grep [b]ash doesn't always work. For example, if you were in /bin when you ran this it would first match the [b]ash argument against the file bash in that directory and then just pass "bash" to grep, killing the effect. So you need to use quotes around the [b]ash part like this:

ps aux | grep "[b]ash"

@climagic