In the 21st century, especially if you're targeting machines that are likely to have bash or zsh, you can count on type being available. (It didn't exist in extremely old unices, as in, from the 1970s or early 1980s.) You can't count on its output meaning anything, but you can count on its returning 0 if there is a command by that name and nonzero otherwise.

which isn't standard and is unreliable in practice. type is the recommended alternative. whereis suffers from the same problems as which and is less common. whence is specific to ksh and zsh.

When that's possible, it would be more reliable to test the existence of a command and test whether its behavior looks reasonable. For example, test the presence of a suitable version of bash by running bash -c 'somecommand', e.g.

# Test for the `-v` operator (which appeared in bash 4.2) if bash -c 'test -v HOME' 2>/dev/null; then … 

Today you can count on almost everything in the Singe UNIX specification version 2 (except for exotic stuff like Fortran and SCCS, which are optional anyway). You can count on most of version 3, too, but this isn't completely implemented everywhere yet. Version 4 support is sketchier. If you're going to read these specs, I recommend reading version 3, which is a lot more readable and less ambiguous than version 2.

For examples as to how to detect system specificities, look at autoconf and at configure scripts of various software.

See also Resources for portable shell programming for more tips.

In the 21st century, especially if you're targeting machines that are likely to have bash or zsh, you can count on type being available. (It didn't exist in extremely old unices, as in, from the 1970s or early 1980s.) You can't count on its output meaning anything, but you can count on its returning 0 if there is a command by that name and nonzero otherwise.

which isn't standard and is unreliable in practice. type is the recommended alternative. whereis suffers from the same problems as which and is less common. whence is specific to ksh and zsh.

When that's possible, it would be more reliable to test the existence of a command and test whether its behavior looks reasonable. For example, test the presence of a suitable version of bash by running bash -c 'somecommand', e.g.

# Test for the `-v` operator (which appeared in bash 4.2) if bash -c 'test -v HOME' 2>/dev/null; then … 

Today you can count on almost everything in the Singe UNIX specification version 2 (except for exotic stuff like Fortran and SCCS, which are optional anyway). You can count on most of version 3, too, but this isn't completely implemented everywhere yet. Version 4 support is sketchier. If you're going to read these specs, I recommend reading version 3, which is a lot more readable and less ambiguous than version 2.

For examples as to how to detect system specificities, look at autoconf and at configure scripts of various software.

See also Resources for portable shell programming for more tips.