몇 개의 디렉토리가 있다고 가정해 보겠습니다.
/Users/user1/ApplicationThing/
/Users/user1/Documents/
/Users/user1/other/directory/it/doesnt/matter/
에 다른 파일에 의존하는 파일이 있다고 가정해 main.sh보겠습니다 ..../ApplicationThing/dependancy.sh
나는 다른 디렉토리에 있을 수 있고 main.shWD를 내 CWD로 사용하여 마치 컨텐츠 .../ApplicationThing/디렉토리가 시스템의 다른 모든 디렉토리에 있는 것처럼 실행할 수 있기를 원합니다. with 와는 달리 $PATH내용이 실제로 디렉토리 내부에 있는 것처럼 보이지만 자동 완성이나 심지어 에서도 팝업되어서는 안 됩니다 ls -l.
답변1
이는 다른 작업 디렉터리로 호출되는 경우에도 특정 위치에서 종속성을 찾으려면 ApplicationThing을 수정해야 하는 것처럼 들립니다.
환경 변수를 설정하여 이를 수행할 수 있습니다.
export ApplicationThingHome=/Users/user1/ApplicantionThing
해당 변수의 값을 사용하여 모든 종속성을 참조합니다 main.sh(변수가 설정되지 않은 경우 선택적으로 좋은 기본값 사용). 예를 들어
${ApplicationThingHome:-/usr/local/ApplicationThingDefaultDir}/dependancy.sh
대신에
./dependancy.sh
그런 다음 님 main.sh의 디렉토리를 $PATH어떤 디렉토리에나 넣고 사용할 수 있습니다.
제안된 솔루션에는 문제가 있습니다. 다른 디렉터리에 있고 이름이 같은 파일을 생성하려는 경우 main.sh대신 dependency.shApplicationThing의 해당 파일을 덮어쓰게 됩니다. 말 그대로 main.shApplicationThing에 속한 것 외에는 다른 것을 가지거나 사용할 수 없습니다 ... 디렉토리는 그런 문제를 피하기 위해 정확하게 고안되었습니다!
물론 "의사 파일"이 main.sh먼저 실행될 때만 존재하도록 조건을 만들 수도 있습니다. 하지만 main.sh그렇게 하지 않을 때마다 문제를 해결하려면 무엇을 볼 수 있는지 확인하는 또 다른 도구 세트가 필요합니다. 당신이 기대하는 것.
ApplicationThing을 수정할 수 없는 경우 시스템 어디에서나 ApplicationThing을 호출하는 래퍼 스크립트를 만들어서 배치할 수 있습니다.저것$PATH에 포함된 디렉토리의 스크립트:
#!/bin/sh
# set the correct working directory for silly ApplicationThing
cd /Users/user1/ApplicationThing
# if ApplicationThing has any other environment requirements,
# this would be a great place to ensure they're satisfied too.
# Now execute the main.sh of ApplicationThing, giving it any
# command line arguments that were given to this script, exactly as-is.
exec ./main.sh "$@"
이 스크립트는 별도의 프로세스로 실행되므로 cd스크립트의 명령은 스크립트를 호출하는 세션에 전혀 영향을 미치지 않습니다. exec실행 시 키워드는 호출 main.sh셸과 main.sh.
이 접근 방식을 사용하면 main.sh파일 이름을 매개 변수로 사용하는 경우 절대 경로 이름으로 제공해야 합니다. 모든 상대 경로 이름은 main.sh호출 세션의 CWD가 아닌 ApplicationThing의 디렉터리를 기준으로 해석되기 때문입니다.
이것이 문제인 경우 명령줄 매개변수를 에 전달하기 전에 해당 매개변수에 대한 보다 정교한 사전 처리를 작성할 수 있습니다 main.sh.이 StackExchange 질문당신이 적용할 수 있는 몇 가지 아이디어가 있습니다.