Differences between revisions 9 and 29 (spanning 20 versions)
Revision 9 as of 2008-11-18 04:14:58
Size: 4037
Editor: GreyCat
Comment: command -v, for POSIX
Revision 29 as of 2025-03-11 22:37:01
Size: 4353
Editor: 81
Comment: mention exit codes of command vs type in POSIX
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
[[Anchor(faq81)]] <<Anchor(faq81)>>
Line 3: Line 3:

The POSIX shell specifies a builtin called {{{command}}} which can be used for this purpose:
POSIX specifies a shell builtins called `command` and `type` which can be used for this purpose. Note that type's exit codes isn't well defined by POSIX whereas command's exit status is well defined by POSIX, so that one is probably the safest to use.
Line 8: Line 7:
if command -v qwerty >/dev/null; then if command -v qwerty > /dev/null; then
Line 13: Line 12:
}}}
Line 15: Line 13:
In BASH, there are a couple more builtins that may also be used: {{{hash}}} and {{{type}}}. Here's an example using {{{hash}}}:

{{{
# Bash
if hash qwerty 2>/dev/null; then
# POSIX (no options in `type`)
if type qwerty > /dev/null; then
Line 24: Line 19:

Line 25: Line 22:

Or, if you prefer {{{type}}}:
In BASH, there is `hash` builtin and `type` with non-POSIX options. Here's are examples:
Line 30: Line 26:
if hash qwerty 2> /dev/null; then
  echo qwerty exists
else
  echo qwerty does not exist
fi

# Bash
# type -P forces a PATH search
# skipping builtins and so on
Line 36: Line 41:

KornShell has {{{whence}}} instead:
KornShell and zsh have `whence` instead:
Line 40: Line 44:
# ksh
if whence -p qwerty >/dev/null; then
# ksh/zsh
if whence -p qwerty > /dev/null; then
Line 47: Line 51:

If these builtins are not available (because you're in a Bourne shell, or whatever), then you may have to rely on the external command {{{which}}} (which is often a csh script, although sometimes a compiled binary). Unfortunately, {{{which}}} may not set a useful exit code, and it may not even write errors to stderr. In those cases, one must parse its output.
The `command` builtin also returns true for shell builtins (unlike `type -P`). If you absolutely must check only PATH, the only POSIX way is to iterate over it:
Line 51: Line 54:
# Bourne. Last resort -- using which(1)
tmpval=`LC_ALL=C which qwerty 2>&1`
if test $rc -ne 0; then
  # FOR NOW, we'll assume that if this machine's which(1) sets a nonzero
  # exit status, that it actually failed. I've yet to see any case where
  # which(1) sets an erroneous failure -- just erroneous "successes".
  echo "qwerty is not installed. Please install it."
# POSIX
IsInPath ()
(
  [ "$1" ] || exit 2
  set -f; IFS=:
  for dir in $PATH$IFS; do
    [ -x "${dir:-.}/$1" ] && exit 0
  done
  exit 1
)
Line 59: Line 65:
if IsInPath qwerty; then
  echo qwerty exists
Line 60: Line 68:
    case "$tmpval" in
      *no\ *\ in\ *|*not\ found*|'')
        echo "qwerty is not installed. Please install it."
 ;;
      *)
        echo "Congratulations -- it seems you have qwerty (in $tmpval)."
 ;;
    esac
  echo qwerty does not exist
Line 70: Line 71:
Note that the function defined above uses parentheses around the body rather than the normal curly braces. This makes the body run in a subshell, and is the reason we don't need to undo `set -f` or [[IFS]].
Line 71: Line 73:
Note that `which(1)`'s output when a command is not found is ''not'' consistent across platforms. On HP-UX 10.20, for example, it prints {{{no qwerty in /path /path /path ...}}}; on OpenBSD 4.1, it prints {{{qwerty: Command not found.}}}; on Debian (3.1 and 4.0 at least) and SuSE, it prints nothing at all; on Red Hat 5.2, it prints {{{which: no qwerty in (/path:/path:...)}}}; on Red Hat 6.2, it writes the same message, but on standard error instead of standard output; and on Gentoo, it writes something on stderr.

So our best portable solution is to match the words `no` and `in`, or the phrase `not found`, in the combined stdout + stderr and pray.

Note to the person who tried to put a function in this FAQ as a legacy Bourne shell example: legacy Bourne shells ''don't have functions'', at all. POSIX shells have them, but the syntax is:

{{{
foo() {
  commands
}
}}}

You may ''not'' use the word `function`, and you may ''especially not'' use the combination of the word `function` and the `()` symbols. No shell but bash accepts that. Also see BashPitfalls.

The approach used in `configure` scripts is usually to iterate over the components of `$PATH` and explicitly test for the presence of the command in each directory. The fact that this is ''preferred'' over `which` should tell you how unreliable `which` is. Here's a ''simplified'' version of such a test:
The iterative approach is also used in `configure` scripts. Here's a ''simplified'' version of such a test:
Line 100: Line 88:
if test $found = no; then if test "$found" = no; then
Line 104: Line 92:
Real `configure` scripts are generally much more complicated than this, since they may deal with systems where `$PATH` is not delimited by colons; or systems where executable programs may have optional extensions like `.EXE`; or `$PATH` variables that have the current working directory included in them as an empty string; etc. If you're interested in such things, I suggest reading an actual GNU autoconf-generated `configure` script. They're far too large and complicated to include in this FAQ.
Line 105: Line 94:
Real `configure` scripts are generally much more complicated than this, since they may deal with systems where `$PATH` is not delimited by colons; or systems where executable programs may have optional extensions like `.EXE`; or `$PATH` variables that have the current working directory included in them as an empty string; etc. If you're interested in such things, I suggest reading an actual GNU autoconf-generated `configure` script. They're far too large and complicated to include in this FAQ. The command `which` (which is often a csh script, although sometimes a compiled binary) is '''not reliable''' for this purpose. `which` may not set a useful exit code, and it may not even write errors to stderr. Therefore, in order to have a prayer of successfully using it, one must parse its output (wherever that output may be written).

{{{
# Bourne. Last resort -- using which(1)
tmpval=`LC_ALL=C which qwerty 2>&1`
if test "$?" -ne 0; then
  # FOR NOW, we'll assume that if this machine's which(1) sets a nonzero
  # exit status, that it actually failed. I've yet to see any case where
  # which(1) sets an erroneous failure -- just erroneous "successes".
  echo "qwerty is not installed. Please install it."

else
    # which returned 0, but that doesn't mean it succeeded. Look for known error strings.
    case "$tmpval" in
      *no\ *\ in\ *|*not\ found*|'')
        echo "qwerty is not installed. Please install it."
        ;;
      *)
        echo "Congratulations -- it seems you have qwerty (in $tmpval)."
        ;;
    esac
fi
}}}
Note that `which(1)`'s output when a command is not found is ''not'' consistent across platforms. On HP-UX 10.20, for example, it prints {{{no qwerty in /path /path /path ...}}}; on OpenBSD 4.1, it prints {{{qwerty: Command not found.}}}; on Debian (3.1 through 5.0 at least) and SuSE, it prints nothing at all; on Red Hat 5.2, it prints {{{which: no qwerty in (/path:/path:...)}}}; on Red Hat 6.2, it writes the same message, but on standard error instead of standard output; and on Gentoo, it writes something on stderr.

Use one of the builtins or the iterative approaches is recommended instead of
`which`.

How can I determine whether a command exists anywhere in my PATH?

POSIX specifies a shell builtins called command and type which can be used for this purpose. Note that type's exit codes isn't well defined by POSIX whereas command's exit status is well defined by POSIX, so that one is probably the safest to use.

# POSIX
if command -v qwerty > /dev/null; then
  echo qwerty exists
else
  echo qwerty does not exist
fi

# POSIX (no options in `type`)
if type qwerty > /dev/null; then
  echo qwerty exists
else
  echo qwerty does not exist
fi

In BASH, there is hash builtin and type with non-POSIX options. Here's are examples:

# Bash
if hash qwerty 2> /dev/null; then
  echo qwerty exists
else
  echo qwerty does not exist
fi

# Bash
# type -P forces a PATH search
# skipping builtins and so on
if type -P qwerty >/dev/null; then
  echo qwerty exists
else
  echo qwerty does not exist
fi

KornShell and zsh have whence instead:

# ksh/zsh
if whence -p qwerty > /dev/null; then
  echo qwerty exists
else
  echo qwerty does not exist
fi

The command builtin also returns true for shell builtins (unlike type -P). If you absolutely must check only PATH, the only POSIX way is to iterate over it:

# POSIX
IsInPath ()
(
  [ "$1" ] || exit 2
  set -f; IFS=:
  for dir in $PATH$IFS; do
    [ -x "${dir:-.}/$1" ] && exit 0
  done
  exit 1
)

if IsInPath qwerty; then
  echo qwerty exists
else
  echo qwerty does not exist
fi

Note that the function defined above uses parentheses around the body rather than the normal curly braces. This makes the body run in a subshell, and is the reason we don't need to undo set -f or IFS.

The iterative approach is also used in configure scripts. Here's a simplified version of such a test:

# Bourne
save_IFS=$IFS
IFS=:
found=no
for dir in $PATH; do
  if test -x "$dir/qwerty"; then
    echo "qwerty is installed (in $dir)"
    found=yes
    break
  fi
done
IFS=$save_IFS
if test "$found" = no; then
  echo "qwerty is not installed"
fi

Real configure scripts are generally much more complicated than this, since they may deal with systems where $PATH is not delimited by colons; or systems where executable programs may have optional extensions like .EXE; or $PATH variables that have the current working directory included in them as an empty string; etc. If you're interested in such things, I suggest reading an actual GNU autoconf-generated configure script. They're far too large and complicated to include in this FAQ.

The command which (which is often a csh script, although sometimes a compiled binary) is not reliable for this purpose. which may not set a useful exit code, and it may not even write errors to stderr. Therefore, in order to have a prayer of successfully using it, one must parse its output (wherever that output may be written).

# Bourne.  Last resort -- using which(1)
tmpval=`LC_ALL=C which qwerty 2>&1`
if test "$?" -ne 0; then
  # FOR NOW, we'll assume that if this machine's which(1) sets a nonzero
  # exit status, that it actually failed.  I've yet to see any case where
  # which(1) sets an erroneous failure -- just erroneous "successes".
  echo "qwerty is not installed.  Please install it."

else
    # which returned 0, but that doesn't mean it succeeded.  Look for known error strings.
    case "$tmpval" in
      *no\ *\ in\ *|*not\ found*|'')
        echo "qwerty is not installed.  Please install it."
        ;;
      *)
        echo "Congratulations -- it seems you have qwerty (in $tmpval)."
        ;;
    esac
fi

Note that which(1)'s output when a command is not found is not consistent across platforms. On HP-UX 10.20, for example, it prints no qwerty in /path /path /path ...; on OpenBSD 4.1, it prints qwerty: Command not found.; on Debian (3.1 through 5.0 at least) and SuSE, it prints nothing at all; on Red Hat 5.2, it prints which: no qwerty in (/path:/path:...); on Red Hat 6.2, it writes the same message, but on standard error instead of standard output; and on Gentoo, it writes something on stderr.

Use one of the builtins or the iterative approaches is recommended instead of which.

BashFAQ/081 (last edited 2025-03-11 22:37:01 by 81)