쉘이/usr/local/bin이 아닌/usr/bin에서 실행 파일을 사용하는 이유

쉘이/usr/local/bin이 아닌/usr/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

/usr/local/bin/cmake이유는 무엇이며, 입력할 때 cmake(별칭 등 없이) 쉘이 실행 파일을 실행하도록 하려면 어떻게 해야 합니까 ?

답변1

문제는 실행하여 드러났습니다.

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

그리고 bash 해시를 지우는 방법

hash -d cmake

그 이후에는 cmake예상대로 해석되었습니다.

답변2

동일한 셸 세션 중 이전 시점에 를 사용했고 cmake해당 실행 파일이 /usr/bin.

그런 cmake다음 /usr/local/bin.

bash은 사용자가 사용하는 외부 명령에 대해 찾은 첫 번째 위치를 캐시합니다. 즉, 다음에 동일한 명령을 사용할 때 실행 파일에 대해 값비싼 검색을 수행할 필요가 없다는 의미입니다. 단점은 보기에 부담스럽지 않다는거다시$PATH나중에 동일한 이름으로 다른 실행 파일을 설치하는 경우, 원래 위치보다 이전에 발생한 디렉터리에 설치한 경우에도 마찬가지입니다 .

이 문제에 대한 해결책은 bash보관된 실행 파일의 캐시된 위치를 비우는 것입니다. 이는 hash -r( 쉘 rehash에서 zsh)로 수행됩니다. 실행 파일 의 위치만 잊어버리려면 ( 셸 에서 ) cmake을 사용하세요 .hash -d cmakeunhash cmakezsh


이 질문의 이전 버전에서는 두 명령이 서로 다른 결과를 제공하는 이유에 대해 추가로 궁금해했는데 type cmake, which cmake여기서 which cmake예상된 결과( /usr/local/bin/cmake) 를 제공하는 것처럼 보이지만 type cmake잘못된 결과( /usr/bin/cmake)를 제공하는 것으로 나타났습니다.

이에 대한 대답은 셸에서 사용하는 것과 동일한 캐시된 명령 위치를 사용하는 type내장 명령 이라는 것 입니다 .bashwhich~ 아니다내장 명령이므로 캐시된 실행 파일 위치를 사용할 수 없습니다.

이 경우 은 (는) 에서 which검색했기 때문에 예상한 결과를 얻었 지만 실제로는cmake$PATH잘못된결과적으로 cmake명령줄에서 실행하면 실제로~ 아니다( 알지 못하는 /usr/local/bin캐싱으로 인해 ) 에서 가져옵니다 .which

의 역사 which와 사용 시의 함정에 대한 요약은 다음에서 찾을 수 있습니다." which "를 사용하지 않는 이유는 무엇입니까? 그러면 무엇을 사용해야 할까요?

관련 정보