Finding a File Using a List of Possible Locations in bash

You need to execute, source, or read a file, but it may be located in a number of different places in or outside of the $PATH.

If you are going to source the file and it’s located somewhere on the $PATH, just source it.

bash’s built-in source command (also known by the shorter-to-type but harder-to-read POSIX name “.”) will search the $PATH if the sourcepath shell option is set, which it is by default:

If you want to execute a file only if you know it exists in the $PATH and is executable, and you have bash version 2.05b or higher, use type -P to search the $PATH.

Unlike the which command, type -P only produces output when it finds the file, which makes it much easier to use in this case:

If you need to look in a variety of locations, possibly including the $PATH, use a for loop.

To search the $PATH, use the variable substitution operator ${variable/pattern/ replacement} to replace the : separator with a space, and then use for as usual.

To search the $PATH and other possible locations, just list them:

If the file is not in the $PATH, but could be in a list of locations, possibly even under different names, list the entire path and name:

Perform any additional tests as needed.

For example, you may wish to use screen when logging in if it’s present on the system:

Using for to iterate through each possible location may seem like overkill, but it’s actually very flexible and allows you to search wherever you need to, apply whatever other tests are appropriate, and then do whatever you want with the file if found.

By replacing : with a space in the $PATH, we turn it into the kind of space-delimited list for expects (but as we also saw, any space delimited list will work).

Adapting this technique as needed will allow you to write some very flexible and portable shell
scripts that can be very tolerant of file locations.
You may be tempted to set $IFS=’:’ to directly parse the $PATH, rather than preparsing it into $path.

That will work, but involves extra work with variables and isn’t as flexible.
You may also be tempted to do something like the following:

The problem here is not when the file exists, but when it doesn’t. The which utility behaves differently on different systems.

The Red Hat which is also aliased to provide details when the argument is an alias, and to set various command-line switches; and it returns a not found message (while which on Debian or FreeBSD do
not).

But if you try that line on NetBSD you could end up trying to bind no myfile in /sbin /usr/sbin /bin /usr/bin /usr/pkg/sbin /usr/pkg/bin /usr/X11R6/bin /usr/ local/sbin /usr/local/bin, which is not what you meant.
The command command is also interesting in this context. It’s been around longer than type -P and may be useful under some circumstances.
Red Hat Enterprise Linux 4.x behaves like this:

Debian and FreeBSD (but not NetBSD or OpenBSD) behave like this: