I need to find the path of a given program on the PATH using a shell script. The path must be the actual full path of the program, which can be passed later to one of the exec* functions, which does not search the PATH itself, e.g. execv.

There are programs like kill, which are available as an actual program and a shell built-in at the same time. If this is case, I need the full path to the actual program.

There are several utilities that can find a program on the PATH as specified in Section, Command Search and Execution of the POSIX standard.

There is which, which is not part of any standard. It can be a regular program on some systems, whereas some shells provide it is a builtin. It seems to be available on most systems and shells, but the shells with a builtin version, also just return the name of the built-in instead of the path to the executable. Also it is not standardized in any way and may return any output and take different options.

bash# which kill
dash# which kill
fish# which kill
mksh# which kill
tcsh# which kill
kill: shell built-in command.
zsh# which kill
kill: shell built-in command

There is whence, which is a built-in of a few shells. But not available on many shells. It will too return the name of the built-in instead of the path to program. A -p may be passed to whence to change this behavior.

bash# whence kill
bash: whence: command not found
dash# whence kill
dash: 1: whence: not found
fish# whence kill
fish: Unknown command 'whence'
mksh# whence kill
mksh# whence -p kill
tcsh# whence kill
whence: Command not found.
zsh# whence kill
zsh# whence -p kill

There is the command builtin specified by POSIX:2008. Unfortunately it also searches for regular commands and built-ins and will return the name of the built-in instead of the path to the program shadowed by a built-in of the same name. Some old shells haven't implemented it yet.

bash# command -v kill
dash# command -v kill
fish# command -v kill
mksh# command -v kill
tcsh# command -v kill
command: Command not found.
zsh# command -v kill
  • I can't figure out if enable is specified in POSIX or not, but if it is, you could use enable -n which to disable the shell built-in for which.
    – Muzer
    Commented Nov 17, 2016 at 15:04
  • and there is realpath Commented Nov 17, 2016 at 15:10
  • @Muzer On the shells I have at my disposal, enable is only provided by bash and zsh Commented Nov 17, 2016 at 15:11
  • 2
    You need a realiable method for the specific shell which is running your script not for all shells. Scripts are not executed by a random shell but specifically by the shell specified in the shebang line. That being said, in bash that would be type -p. Both bash and dash let you say command command to run an actual executable even if there is a function or builtin with the same name.
    – AlexP
    Commented Nov 17, 2016 at 15:31
  • 1
    @AlexP command skips functions (and aliases) but NOT builtins, as the Q correctly says. And you can't always use a shebang because there is no path that gets any given shell, or even some POSIX shell, on all systems. Commented Nov 17, 2016 at 19:21

1 Answer 1


Just search for it yourself.

export IFS=":"
[ -z "${1}" ] && exit 1
for dir in $PATH
do if [ -x "${dir}/${1}" ]
   then echo "${dir}/${1}"
        exit 0
echo ${1} not found
exit 1

Tested in bash, dash, ksh, mksh, zsh


The above is nice for a stand alone script however if you're planning on embedding this into a larger script you may want to use something more like the following.

function find_path() {
   export IFS=":"
   [ -z "${1}" ] && return 1
   for dir in $PATH
   do if [ -x "${dir}/${1}" ]
      then echo "${dir}/${1}"
           export IFS="${IFS_SAVE}"
           return 0
   export IFS="${IFS_SAVE}"
   echo ${1} not found
   return 1

This is so that IFS is restored after finding the match, also swapped exit's with return's

  • 1
    Maybe -x instead of -f?
    – Jeff Schaller
    Commented Nov 17, 2016 at 16:58
  • @JeffSchaller good point, no reason to pick out non-executable files. Commented Nov 17, 2016 at 17:01
  • 3
    If you integrate this into a larger shell script (as opposed to making it into a script in its own right, as is presumably intended), you might want to restore the old value of IFS afterwards - otherwise that could have a lot of effects on the rest of the script...
    – psmears
    Commented Nov 17, 2016 at 17:34
  • Why export the IFS variable? Isn't it enough to have this set in the local shell? Speaking of local, would local IFS be portable? The above may interact poorly if something else is saving IFS the same way. Looking at this question on SE, local may work for most shells despite not being POSIX. Putting the original version in a (…) subshell might work as well.
    – MvG
    Commented Nov 17, 2016 at 20:00
  • @ZacharyBrady I believe the function can be more defensive by checking if the argument ${1} is an empty string before redefining the IFS environment variable. Commented Jun 20 at 1:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .