/usr/local/bin 프로그램이 /usr/local/sbin에 복사되는 이유는 무엇입니까?

/usr/local/bin 프로그램이 /usr/local/sbin에 복사되는 이유는 무엇입니까?

지금은 재현할 수 없는 것 같은데 /usr/local/bin에 추가했던 프로그램 중 일부가 /usr/local/sbin.

나는 bash 스크립트를 작성했기 때문에 이것을 알아차렸는데 당시 터미널에서 실행했을 때 전혀 실행되지 않는 이유를 이해하지 못했습니다. 나는 whereas모든 것이 주석 처리된 오래된 사본을 사용하고 발견했습니다 /usr/local/sbin. 파일을 제거한 후 .../sbin명령줄에서 작업자 스크립트를 실행하면 실행됩니다..../bin

이전 whereis에 나열된 파일의 출력입니다 . 스크립트가 우선하는 이유는 무엇입니까? 그리고 이 파일이 왜 복사되었는지 아시나요? 문제를 깨닫기 전에 문제를 해결하려고 시도하면서 "sbin"으로 "bin"을 여러 번 입력했을 수도 있지만 그럴 가능성은 거의 없습니다.binsbinsbinsbin

답변1

내가 아는 한, 배포판에는 사용자가 입력한 스크립트를 복사할 수 있는 메커니즘이 없으며 /usr/local/bin그 반대의 경우도 마찬가지입니다 /usr/local/sbin.

bash실행된 명령의 경로 이름을 캐시하고 때로는 해당 캐시를 플러시하기 위해 해당 명령을 사용해야 한다는 것을 알고 계셨습니까 hash?

작업 버전을 추가하기 전에 명시적인 경로 없이 스크립트 명령을 시도하면 /usr/local/bin쉘은 주석 처리된 버전을 찾아 /usr/local/sbin해당 경로 이름을 캐시하고 나머지 세션 동안 이를 기억합니다. 작업 버전이 추가된 후에도 (경로 검색 다시 실행 ) 또는 (셸 세션에 대한 전체 경로 캐시 플러시)을 실행하지 않는 한 /usr/local/bin셸 세션은 해당 버전을 계속 사용합니다 ./usr/local/sbinhash <scriptname><scriptname>hash -r

또한 셸은 명령이 해시된 위치에 더 이상 존재하지 않는 경우 이전에 해시된 명령의 전체 검색을 자동으로 다시 실행합니다. 이는 /usr/local/sbin/<scriptname>제거 후 예상 동작이 복원되는 이유를 설명합니다.

whereis은 쉘의 내부 명령이 아니므로 내부 경로 캐시에 대해 아무것도 모릅니다 bash. bash내 이론이 맞다면 이 type <scriptname>명령( 와 유사 whereis하지만 내장되어 있음 bash)은 다음을 보고합니다.

<scriptname> is hashed (/usr/local/sbin/<scriptname>)

발생한 동작을 트리거하려면 먼저 주석이 달린 스크립트 버전을 복사한 /usr/local/sbin다음 스크립트 버전이 아직 에 존재하지 않을 때 명시적인 경로 없이 한 번 실행해 보는 것으로 충분합니다 /usr/local/bin. 이것은 bin -> sbin의 철자를 한 번만 틀리게 하면 됩니다.

관련 정보