Допустим, у меня есть несколько каталогов:
/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и использовать его из любого каталога.
Ваше предложенное решение будет иметь проблему: если вы находитесь в любом другом каталоге и хотите создать файл с именем, скажем, main.shили dependency.shтам, вы в конечном итоге вместо этого перезапишете соответствующие файлы ApplicationThing. Вы буквально не сможете иметь/использовать ничего другого, main.shкроме того, который принадлежит ApplicationThing... и каталоги были придуманы именно для того, чтобы избежать таких проблем!
Конечно, можно сделать условием, что «псевдофайлы» будут там только при 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как относительные к каталогу ApplicationThing, а не как относительные к CWD вызывающего сеанса.
Если это проблема, вы можете написать более сложную предварительную обработку параметров командной строки перед их передачей в main.sh.Этот вопрос StackExchangeесть несколько идей, которые вы можете счесть применимыми.