여러 디렉터리가 있다고 가정해 보겠습니다.
/Users/user1/ApplicationThing/
/Users/user1/Documents/
/Users/user1/other/directory/it/doesnt/matter/
main.sh.../ApplicationThing/그 안에 다른 파일에도 의존하는 파일이 있다고 가정해 보세요 dependancy.sh.
나는 다른 디렉터리에 있을 수 있고 콘텐츠 디렉터리가 시스템의 다른 모든 디렉터리에 있는 main.sh것처럼 WD를 내 CWD로 실행할 수 있기를 원합니다. .../ApplicationThing/와는 달리 $PATH내용이 실제로 디렉토리 내부에 있는 것처럼 보이지만 자동 완성 기능에도 있어서는 안 됩니다 ls -l.
답변1
이는 다른 작업 디렉터리로 호출되는 경우에도 특정 위치에서 종속성을 찾도록 ApplicationThing을 수정해야 하는 것처럼 들립니다.
환경 변수를 설정하여 이를 수행할 수 있습니다.
export ApplicationThingHome=/Users/user1/ApplicantionThing
해당 변수 값을 사용하는 모든 종속성을 참조합니다 main.sh(변수가 설정되지 않은 경우 적절한 기본값을 선택할 수 있음).
${ApplicationThingHome:-/usr/local/ApplicationThingDefaultDir}/dependancy.sh
바꾸다
./dependancy.sh
main.sh그런 다음 해당 디렉토리를 임의의 디렉토리에 넣고 $PATH임의의 디렉토리에서 사용할 수 있습니다 .
제안된 솔루션에 문제가 있습니다. 다른 디렉터리에 있고 또는이라는 파일을 생성하려는 경우 결국 ApplicationThing에 해당하는 파일을 덮어쓰게 됩니다 main.sh. dependency.sh말 그대로 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스크립트의 명령은 스크립트를 호출하는 세션에 전혀 영향을 미치지 않습니다. execrunning 키워드는 main.sh쉘 및 main.sh.
이 접근 방식을 사용하면 파일 이름을 인수로 전달하는 경우 절대 경로 이름으로 제공해야 합니다. 모든 상대 경로 이름은 호출 세션의 CWD가 아닌 ApplicationThing 디렉터리를 기준 main.sh으로 해석되기 때문입니다 .main.sh
이것이 문제가 되는 경우 명령줄 인수를 main.sh.이 StackExchange 질문다음은 귀하에게 적용될 수 있는 몇 가지 아이디어입니다.