☰

为什么 shell 使用 /usr/bin 中的可执行文件而不是 /usr/local/bin 中的可执行文件

tag-icon • tag-icon bash
为什么 shell 使用 /usr/bin 中的可执行文件而不是 /usr/local/bin 中的可执行文件

鉴于：

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

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

为什么会这样，以及如何让 shell/usr/local/bin/cmake在我键入时运行可执行文件cmake（没有别名等）？

答案1

通过运行发现了问题

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

并清除 bash 哈希值

hash -d cmake

此后，cmake被解释为预期的。

答案2

在同一 shell 会话的早期某个时刻，您使用过cmake并且在 中找到了该可执行文件/usr/bin。

然后您安装了另一个cmake可执行文件/usr/local/bin。

shellbash会缓存它为您使用的任何外部命令找到的第一个位置，这意味着您下次使用同一命令时，它不必对可执行文件进行昂贵的搜索。这样做的缺点是懒得去看再次当您稍后安装同名的另一个可执行文件时，即使它是在早$PATH于原始位置的目录中完成的。

此问题的解决方案是清空bash保留的可执行文件的缓存位置。这是通过hash -r(rehash在zshshell 中) 完成的。如果只想忘记可执行文件的位置cmake，请使用hash -d cmake(unhash cmake在zshshell 中)。

这个问题的早期版本还想知道为什么这两个命令type cmake给出which cmake了不同的结果，其中which cmake似乎给出了预期的结果（/usr/local/bin/cmake），而type cmake似乎给出了错误的结果（/usr/bin/cmake）。

答案是，这type是一个内置命令，bash它将使用与 shell 使用的命令相同的缓存位置，which即不是内置命令，因此将无法使用可执行文件的这些缓存位置。

在本例中，给出了预期的结果，因为它在您的 中which进行了搜索，但实际上是cmake$PATH错误的结果，因为cmake在命令行上运行实际上会不是/usr/local/bin从（由于缓存，这是不知道的）中获取它which。

的历史总结which以及使用它的陷阱可以在这里找到：为什么不用“哪个”呢？那该用什么呢？

相关内容