This page describes some common utilities that should be avoided, and what to use instead. <> == 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 [[https://gitlab.com/procps-ng/procps/blob/master/README.md|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 there's a choice it's better to just 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 == On some systems (Linux-based ones, usually) this may try to send a signal to a bunch of processes based on their names (a dodgy practice at best -- see above). On others (Unix System V-based ones) it will try to kill ''every running process'' regardless of name. In either case, it's nonstandard. === Alternatives === Use `pkill`, also from [[https://gitlab.com/procps-ng/procps/blob/master/README.md|procps]]. But see ProcessManagement for proper ways to manage processes. == 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, an error to stdout, or an error to stderr. It may or may not return a non-zero exit status. If the `which` command 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 other 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. Consider replacing it with a more modern alternative. Specifically, `xargs` splits its input on any kind of whitespace, and parses quotes. A filename with spaces or quotes in its name will not be preserved and passed along correctly. GNU `xargs` has a `-0` option that suppresses those misfeatures, but only for NUL-delimited input streams (e.g. those produced by GNU `find` with the `-print0` option). But it's much cleaner and simpler to just use `find ... -exec foo {} +` and skip `xargs` altogether, especially if parallelism is unimportant. === Alternatives === See UsingFind for better ways to execute a command with a whole bunch of files as arguments. Another alternative is [[http://en.wikipedia.org/wiki/GNU_parallel|GNU Parallel]] (which ironically had some odd behaviors to explain in its earlier versions...). == expr == Pure legacy program. Has no real use in a Bash script. The Bourne shell could not do arithmetic, so you had to call this external utility to increment a loop counter. Even POSIX sh can do that much. === Alternatives === For arithmetic, use `$((...))`, `((...))` or `let`. For various string manipulations and tests, see [[BashFAQ/100|FAQ 100]] or [[BashFAQ/031|FAQ 31]]. == seq == `seq` is non-standard and almost always used where brace expansion, shell arithmetic, or some other native shell feature would be more appropriate. Don't use `seq` in a command substitution to produce numbers as arguments - e.g. in a `for` loop. If a stream of digits produced on stdout is actually needed for some other reason then `seq` may be an efficient choice especially if the output will be large enough to offset the cost of forking an external utility, it's just not very portable. Don't use `$(seq)`. === Alternatives === * bash2.04+/ksh93/zsh: `for ((i = 1; i <= 10; i++)); do ...` * bash3.0+/ksh93/zsh: `for i in {1..10}; do ...` * POSIX: `i=0; while [ "$i" -lt 10 ]; do ...; i=$((i + 1)); done` See also [[http://mywiki.wooledge.org/BashGuide/TestsAndConditionals#Conditional_Loops|conditional loops]].