why does shell use executable in /usr/bin and not in /usr/local/bin

Question

Given:

/usr/local/bin/cmake
/usr/bin/cmake
$ cmake # runs /usr/bin/cmake

$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin

Why this, and how do I make the shell run the executable /usr/local/bin/cmake when I type cmake (without aliases and the like)?

If that is your path, the cmake in /usr/local/bin should take precedence. What is the output of which cmake and type -a cmake? — , Nov 29 '19 at 13:31
which points to /usr/local/bin/cmake; type -a returns two lines, one for each. type -f returns: cmake is hashed (/usr/bin/cmake) — user907323, Nov 29 '19 at 13:34
@Kusalananda Please try to avoid recommending which since this is software designed for csh from 1979 that does not work well together with shells similar to the Bourne Shell. Rather use type, as this is built into the shell and knows how your current shell will decide. — schily, Nov 29 '19 at 14:21
@schily I don't think I ever have recommended which. If I did, let me know where and I'll correct it. — Kusalananda, Nov 29 '19 at 14:47
Well, the problem is the title of the article that you copied without comment in your comment. It at the first glance looks as if you recommend which. — schily, Nov 29 '19 at 14:57
@schily That's a canonical question relating to the issues with which. — Kusalananda, Nov 29 '19 at 15:10
This has been asked before. For examples see https://unix.stackexchange.com/q/91173/5132 and https://unix.stackexchange.com/q/39817/5132 . — JdeBP, Nov 29 '19 at 15:33
@schily An early version of this question featured references to the output of which, hence the link could have been relevant. — user907323, Nov 29 '19 at 15:33

score 3 · Answer 1 · answered Nov 29 '19 at 14:10

3

The problem was revealed by running

$ type -f cmake
cmake is hashed (/usr/bin/cmake)

And clearing the bash hash with

hash -d cmake

After this, cmake was interpreted as expected.

answered Nov 29 '19 at 14:10

user907323

175

Kusalananda · Answer 2 · 2019-12-20T12:46:13.100

At some earlier point during the same shell session, you have used cmake and that executable was found in /usr/bin.

You then installed another cmake executable in /usr/local/bin.

The bash shell caches the first location that it finds for any external command that you use, which means it doesn't have to do an expensive search for the executable the next time you use the same command. The downside of this is that it won't bother to look again when you, later, install another executable by the same name, even if it's done in a directory that occurs earlier in $PATH than the original location.

The solution to this issue is to empty the cached locations of executables that bash keeps. This is done with hash -r (rehash in the zsh shell). To only forget the location of the cmake executable, use hash -d cmake (unhash cmake in the zsh shell).

An earlier version of this question additionally wondered why the two commands type cmake and which cmake gave different results, where which cmake appeared to give the expected result (/usr/local/bin/cmake) while type cmake appeared to give the wrong result (/usr/bin/cmake).

The answer to that is that type is a built-in command in bash that will use the same cached locations of commands that the shell uses, and that which is not a built-in command and will therefore not be able to use those cached locations of executables.

In this case, which gave the expected result because it did a search for cmake in your $PATH, but it was in fact the wrong result, since running cmake on the command line would in fact not pick it up from /usr/local/bin (due to the caching, which which would be unaware of).

A summary of the history of which, and the pitfalls of using it, is found here: Why not use "which"? What to use then?

why does shell use executable in /usr/bin and not in /usr/local/bin

2 Answers2