This page describes some common utilities that should be avoided, and what you should use instead.
Contents
pidof
pidof is a strange program. On some systems it's a symlink to the killall5 program - part of the sysvinit package. It is used by init to send signals to all processes (e.g. to kill them during shutdown). If invoked as pidof, it returns the pid of the given program. pidof Is highly nonstandard, yet seen frequently in examples likely due to its intuitive name.
Alternatives
The pgrep utility - part of the procps suite. pgrep returns pids of processes matching the given regex, and is very preferable to grepping ps output. While also nonstandard, pgrep is widely available (if not installed by default) and the utilities are generally good quality. procps also includes a pidof implementation, so if you have a choice you should definitely install it and avoid the sysvinit version.
Process names are NOT a reliable way to work with processes! Searching by name should only be done interactively in a pinch when the need to follow a process couldn't be anticipated. Never do it in scripts or programs! See: ProcessManagement.
killall
See above.
Alternatives
Use pkill, also from procps.
which
which is a non-standard command, though commonly available. It is useless and redundant, both in scripts and interactive shells. Some common bad usages:
# Wrong GREP=`which grep` ... $GREP rm logfile
What happens here is that which searches for grep in the PATH environment variable, and outputs the path to the first grep it finds. If it doesn't find it, it might output nothing, output an error to stdout, or output an error to stderr, and it may or may not return a non-zero exit status. If you happen to have a which command that outputs nothing when the command is not found, the above may result in the GREP variable being empty, in which case $GREP rm logfile expands into rm logfile, which does something else than search for the string "rm" in logfile.
# Right grep rm logfile
Guess what, bash can also search through PATH for commands, in addition to first looking for aliases, functions or builtins by that name. So the which command added nothing useful, only bugs.
The other common use of which is to check if a command exists. The shell can do this already (for example using type), and better, so why use an inferior, external command?
Alternatives
The builtins type, command and hash. See BashFAQ/081
xargs
xargs is standard and moderately useful, but it has a number of unfortunate legacy warts which makes it somewhat cumbersome and sometimes outright dangerous to use. If you have a choice, consider replacing it with a more modern alternative.
Alternatives
The foremost alternative is GNU Parallel (which ironically had some odd behaviors to explain in its earlier versions...)
expr
Alternatives
(()), let