How to use which(1) with the system’s default $PATH

environment-variablespathwhich

I would like to use which with the system's default path, ignoring any embellishments from the user's shell configuration files.

Motivation

I am attempting to write a script to find the system's Ruby binary. Many Ruby developers use a Ruby version manager, which adds something like ~/.rvm/bin to the start of their $PATH. I want to bypass this and use the version of Ruby that came with the system, or was installed via the system's package manager.

Current solution

Here's what I've tried so far:

$ env -i sh -c "which ruby"

This gives no output, and exits with 1. I would expect it to work though, because the path includes /usr/bin, and my system came with a Ruby binary at /usr/bin/ruby:

$ env -i sh -c "echo \$PATH"
/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:.
$ which -a ruby
# ...
/usr/bin/ruby

A few additional details:

env -s bash -c "which ruby" also doesn't find anything.
env -i zsh -c "which ruby" does find /usr/bin/ruby, but I can't depend on zsh.
Using the full path to which (to make sure I'm using the binary, not the shell built-in) doesn't make any difference.

My environment

I'm writing this in Bash on OS X, but would like it to be portable to other shells and operating systems.

Best Answer

command -pv uses a "default value for PATH".

$ which ruby
/home/mikel/.rvm/rubies/ruby-1.9.3-p484/bin/ruby

$ command -pv ruby
/usr/bin/ruby

Unfortunately that doesn't work in zsh, so based on Stephane's comment, we could use getconf PATH:

$ PATH=$(getconf PATH) which ruby

or use command -v in place of which, as recommended in Why not use "which"? What to use then?

$ PATH=$(getconf PATH) command -v ruby

The downside with these approaches is that if the system administrator installed a system-wide version into say /usr/local/bin or /opt/local/bin, and all users had that in PATH (e.g. via /etc/profile or /etc/environment or similar), the above probably wouldn't find it.

In your specific case, I'd suggest trying something specific to Ruby. Here's some ideas that might work:

Filter out versions in the user's home directory (and relative paths):

(
    IFS=:
    set -f
    for dir in $PATH; do
        case $dir/ in
            "$HOME/"*) ;;
            /*/)
                if [ -f "$dir/ruby" ] && [ -x "$dir/ruby" ]; then
                    printf '%s\n' "$dir/ruby"
                    break
                fi;;
        esac
    done
)

Filter out versions in the rvm directory

(
    IFS=:
    set -f
    for dir in $PATH; do
        case $dir/ in
            "$rvmpath/"*) ;;
            /*/)
                if [ -f "$dir/ruby" ] && [ -x "$dir/ruby" ]; then
                    printf '%s\n' "$dir/ruby"
                    break
                fi;;
        esac
    done
)

Filter out writeable rubies (last resort, assumes not running as root)

(
    IFS=:
    set -f
    for dir in $PATH; do
        case $dir/ in
            /*/)
                ruby=$dir/ruby
                if [ -f "$ruby" ] && [ -x "$ruby" ] && [ ! -w "$ruby" ]; then
                    printf '%s\n' "$ruby"
                    break
                fi;;
        esac
    done
)

Ask rvm, chruby, etc.

(
    rvm system
    chruby system
    command -v ruby
)

The last way makes rvm select the default Ruby, but we do it in a subshell, so that the user's preferred Ruby is restored afterwards. (chruby part untested.)

Related Solutions

Bash – How to force the use of a specific binary when running a script

You say NOTE: It is not an option to temporary change the PATH variable just for this command, because this will affect other dependencies, but I think it is an option if you do it right.

You can create a personal directory that has only your desired php in it, and put that personal directory first in your own PATH. That personal PATH entry will affect the shell finding only that one php binary, and not affect any other PATH dependencies. Other people running the script won't use your PATH, so it won't affect them. For example:

$ mkdir -p "$HOME/myphp"
$ ln -s /usr/bin/php "$HOME/myphp/"
$ PATH=$HOME/myphp:$PATH
$ ./script.sh

The above method only affects the one php program, nothing else, and it only affects it for you, not anyone else.

Of course you can put your new PATH definition in the shell start-up file for your account so that only the commands you run will use this version of php.

Shell – Will $0 always include the path to the script

In the most common cases, $0 will contain a path, absolute or relative to the script, so

script_path=$(readlink -e -- "$0")

(assuming there's a readlink command and it supports -e) generally is a good enough way to obtain the canonical absolute path to the script.

$0 is assigned from the argument specifying the script as passed to the interpreter.

For example, in:

the-shell -shell-options the/script its args

$0 gets the/script.

When you run:

the/script its args

Your shell will do a:

exec("the/script", ["the/script", "its", "args"])

If the script contains a #! /bin/sh - she-bang for instance, the system will transform that to:

exec("/bin/sh", ["/bin/sh" or "the/script", "-", "the/script", "its", "args"])

(if it doesn't contain a she-bang, or more generally if the system returns a ENOEXEC error, then it's your shell that will do the same thing)

There's an exception for setuid/setgid scripts on some systems, where the system will open the script on some fd x and run instead:

exec("/bin/sh", ["/bin/sh" or "the/script", "-", "/dev/fd/x", "its", "args"])

to avoid race conditions (in which case $0 will contain /dev/fd/x).

Now, you may argue that /dev/fd/x is a path to that script. Note however that if you read from $0, you'll break the script as you consume the input.

Now, there's a difference if the script command name as invoked doesn't contain a slash. In:

the-script its args

Your shell will look up the-script in $PATH. $PATH may contain absolute or relative (including the empty string) paths to some directories. For instance, if $PATH contains /bin:/usr/bin: and the-script is found in the current directory, the shell will do a:

exec("the-script", ["the-script", "its", "args"])

which will become:

exec("/bin/sh", ["/bin/sh" or "the-script", "-", "the-script", "its", "args"]

Or if it's found in /usr/bin:

exec("/usr/bin/the-script", ["the-script", "its", "args"])
exec("/bin/sh", ["/bin/sh" or "the-script" or "/usr/bin/the-script",
     "-", "/usr/bin/the-script", "its", "args")

In all those cases above except the setuid corner case, $0 will contain a path (absolute or relative) to the script.

Now, a script can also be called as:

the-interpreter the-script its args

When the-script as above doesn't contain slash characters, the behaviour varies slightly from shell to shell.

Old AT&T ksh implementations were actually looking up the-script unconditionally in $PATH (which was actually a bug and a security hole for setuid scripts), so $0 actually did not contain a path to the script unless the $PATH lookup actually happened to find the-script in the current directory.

Newer AT&T ksh would try and interpret the-script in the current directory if it's readable. If not it would lookup for a readable and executable the-script in $PATH.

For bash, it checks if the-script is in the current directory (and is not a broken symlink) and if not, lookup for a readable (not necessarily executable) the-script in $PATH.

zsh in sh emulation would do like bash except that if the-script is a broken symlink in the current directory, it would not search for a the-script in $PATH and would instead report an error.

All the other Bourne-like shells don't look the-script up in $PATH.

For all those shells anyway, if you find that $0 doesn't contain a / and is not readable, then it probably has been looked up in $PATH. Then, as files in $PATH are likely to be executable, it's probably a safe approximation to use command -v -- "$0" to find its path (though that wouldn't work if $0 happens to also be the name of a shell builtin or keyword (in most shells)).

So if you really want to cover for that case, you could write it:

progname=$0
[ -r "$progname" ] || progname=$(
    IFS=:; set -f
    for i in ${PATH-$(getconf PATH)}""; do
      case $i in
        "") p=$progname;;
        */) p=$i$progname;;
        *) p=$i/$progname
      esac
      [ -r "$p" ] && exec printf '%s\n' "$p"
    done
    exit 1
  ) && progname=$(readlink -e -- "$progname") ||
  progname=unknown

(the "" appended to $PATH is to preserve a trailing empty element with shells whose $IFS acts as delimiter instead of separator).

Now, there are more esoteric ways to invoke a script. One could do:

the-shell < the-script

Or:

cat the-script | the-shell

In that case, $0 will be the first argument (argv[0]) that the interpreter received (above the-shell, but that could be anything though generally either the basename or one path to that interpreter).

Detecting that you're in that situation based on the value of $0 is not reliable. You could look at the output of ps -o args= -p "$$" to get a clue. In the pipe case, there's no real way you can get back to a path to the script.

One could also do:

the-shell -c '. the-script' blah blih

Then, except in zsh (and some old implementation of the Bourne shell), $0 would be blah. Again, hard to get to the path of the script in those shells.

Or:

the-shell -c "$(cat the-script)" blah blih

etc.

To make sure you have the right $progname, you could search for a specific string in it like:

progname=$0
[ -r "$progname" ] || progname=$(
    IFS=:; set -f
    for i in ${PATH-$(getconf PATH)}:; do
      case $i in
        "") p=$progname;;
        */) p=$i$progname;;
        *) p=$i/$progname
      esac
      [ -r "$p" ] && exec printf '%s\n' "$p"
    done
    exit 1
  ) && progname=$(readlink -e -- "$progname") ||
  progname=unknown

[ -f "$progname" ] && grep -q 7YQLVVD3UIUDTA32LSE8U9UOHH < "$progname" ||
  progname=unknown

But again I don't think it's worth the effort.