☰

PATH를 업데이트하는 대신 opt에서 실행 파일에 대해 심볼릭 링크가 선호되는 솔루션인 이유는 무엇입니까? [폐쇄]

tag-icon • tag-icon shell filesystems path
PATH를 업데이트하는 대신 opt에서 실행 파일에 대해 심볼릭 링크가 선호되는 솔루션인 이유는 무엇입니까? [폐쇄]

이것에답변모든 /opt/tool/bin 하위 디렉터리를 PATH에 추가하는 방법을 제공합니다.

for d in /opt/*/bin; do PATH="$PATH:$d"; done

그러나 Giles는 이렇게 말했습니다.

그러나 이것은 거의 이루어지지 않습니다. 비표준 디렉터리의 실행 파일이 $PATH에 있는 경우 일반적인 접근 방식은 경로의 디렉터리(예: /usr/local/bin)에 기호 링크를 만드는 것입니다. 이것가게이와 관련하여 유틸리티(또는 xstow)가 유용할 수 있습니다.

마지막 하나다른답변은 이 주장을 뒷받침합니다.

/opt/*/bin그러나 실행 파일에 대한 심볼릭 링크가 바람직한 이유를 이해하지 못합니다 . 이로 인해 불필요한 추가 유지 관리가 추가되는 것 같습니다.

PATH를 업데이트하는 대신 opt에서 실행 파일에 대해 심볼릭 링크가 선호되는 솔루션인 이유는 무엇입니까?

답변1

질문에 답하려고 노력하지만 어떤 솔루션이 "최적"인지 말하는 것이 아니라 Giles가 심볼릭 링크를 사용하여 도구 세트를 제공하고 유지 관리 측면을 해결하도록 제안하는 이유를 설명하기 위한 것입니다. 결국 시스템에 적합한 솔루션이 무엇인지 결정하는 것은 로컬 관리자의 몫입니다.

bin새 도구를 추가하려면 사용자의 디렉토리를 추가하여 모든 PATH사용자에 대한 변수를 업데이트해야 합니다 PATH(이 변수는 새 셸 세션이 시작될 때까지 적용되지 않습니다).

GNU를 사용하면 Gilles가 제안한 대로 예를 들어 각 도구마다 하나의 디렉터리, 각 도구에는 자체 하위 디렉터리 등이 stow있는 디렉터리 구조가 있습니다 . 각 도구는 일반적 으로 설치 접두사를 지정하여 설치됩니다./opt/stowbinlib/opt/stow/toolname

/opt하위 디렉토리 는 해당 디렉토리와 심볼릭 링크되므로 stow유지 관리 비용이 최소화됩니다. 추가해야 할 유일한 디렉토리는 PATH./opt/bin/opt/sbin

일반적으로 귀하는

/opt/stow/tool-A-1.23
/opt/stow/tool-A-1.25
/opt/stow/tool-B-3.0

그 다음에:

cd /opt/stow
stow tool-A-1.23
stow tool-B-3.0

이렇게 하면 /opt적절한 심볼릭 링크로 계층 구조가 채워져 에 액세스할 수 있습니다 /opt/bin. 이는 도구 실행 파일 간에 이름 충돌이 없다고 가정하지만, 이러한 모든 경로를 PATH.

1.23에서 1.25로 전환하려면 tool-A,

cd /opt/stow
stow -D tool-A-1.23
stow tool-A-1.25

수동으로 심볼릭 링크를 유지 관리하거나 사용자의 를 변경할 필요가 없으며 PATH변경 사항은 모든 사용자에게 즉시 적용됩니다.

답변2

모든 것을 넣는 /opt/*/bin것의 단점 PATH은 새로운 응용 프로그램이 설치되거나 다른 응용 프로그램이 업데이트될 때마다(경로가 변경됨) 목록을 변경해야 한다는 것입니다.

사용자는 다시 로그인하거나 경로를 수동으로 업데이트해야 합니다. 간단한 로그인-뭔가-로그아웃 사용 사례의 경우 이는 문제가 되지 않을 수 있지만, screenorb를 실행하는 사람처럼 장기 실행 세션의 경우 tmux문제가 됩니다. (이전 버전으로 실행되는 쉘(또는 Emacs)이 있을 수 있으며 PATH터미널 멀티플렉서 자체도 이전 버전을 사용하게 됩니다 PATH. 이는 유틸리티를 직접 실행하는 경우 중요합니다.)

또한 이로 인해 사용자가 보기를 원하지 않는 시각적으로 불쾌한 디렉토리 목록이 생성될 수 있습니다. PATH에 설치하는 데 신경 쓸 필요가 없는 경우 /opt.

또한 PATH에서 명시적으로 설정 해야 하는 경우 에서 실제 디렉터리 목록을 작성하고 업데이트하는 대신 이와 같은 내용을 작성하는 것이 crontab더 쉬울 것입니다 . NET에서는 루프와 글로브를 사용할 수 없습니다 ./bin:/usr/bin/:/opt/bin/optcrontab

관리비의 경우,코살로난다 토론stowln -s ../someutil-1.2.3/bin/* ., 그러나 이것이 없더라도 내에서 실행하여 필요한 심볼릭 링크를 생성할 수 있습니다 /opt/bin. (이전 것을 삭제하는 것은 아닙니다저것사소하지만 유틸리티 디렉토리를 삭제할 때 끊어진 링크를 남겨두는 것은 쉘의 동작에 영향을 주지 않으며 단지 약간 깨끗하지 않을 뿐입니다. )

답변3

해결해야 할 주요 문제는 프로그램 이름 충돌입니다.

PATH1977년부터 Bourne Shell에 바이너리 경로 위치의 해시가 존재했기 때문에 큰 값을 갖는 것은 더 이상 문제가 되지 않습니다.

다음 한 가지 이유를 제외하면 기호 링크는 일반적이지 않습니다.

클러스터 보기와 다른 자체 프로그램 선택 기능이 있습니다.

예를 들어 PATH를 다음과 같이 설정한 경우:

PATH=/usr/gnu/bin:/usr/bin

표준 시스템 도구보다 먼저 모든 GNU 도구를 찾을 수 있습니다.

chmod이를 통해 GNU 도구를 쉽게 사용할 수 있지만 예를 들어 ACL을 지원하지 않고 tar이식성 문제가 있는 아카이브를 생성하는 것으로 알려진 GNU를 사용하는 GNU를 사용해야 하는 결과도 발생합니다 .

xgettext당신이 기본적으로 GNU에 관심이 있지만 GNU 도구에 알려지지 않은 확장된 시스템 기능에 대한 지원을 포함하는 공식 시스템 도구를 사용하는 것을 선호한다고 가정해 보겠습니다 . 예를 들어 다음과 같이 자신만의 bin 디렉토리를 생성하면 됩니다.

mkdir ~/bin

그런 다음 심볼릭 링크를 만드는 경우:

cd ~/bin
ln -s /usr/gnu/bin/xgettext

다음 경로를 설정합니다.

PATH=~/bin:/usr/bin:/usr/gnu/bin

xgettext를 호출하면 GNU xgettext를 얻지만 예를 들어 호출하거나 xgettext공식 시스템 도구를 얻으면 됩니다. GNU 도구에 대한 심볼릭 링크가 있는 경우가 많지만 기본 접두사(예: to )가 있으므로 tar 를 호출하여 의도적으로 GNU tar를 사용할 수 있습니다.chmodtar/usr/bin//usr/bin/gtar/usr/gnu/bin/targtar

참고: /opt/binUNIX FHS 표준의 일부가 아닙니다.

/opt/<vendor>/bin

설마

/opt/<project>/bin

하지만 후자의 예도 있습니다.

관련 정보