является источником файла, уже полученного в родительском скрипте, необязательно?
Я считаю, что то, о чем вы просите, называется закладкой. Два подхода, которые я видел для этого, заключаются в том, чтобы либо поддерживать набор псевдонимов, либо использовать инструмент для «создания закладок» для некоторого длинного пути к каталогу, а затем использовать этот инструмент для «перехода» к каталогу, отмеченному закладками.
Метод №1 - Псевдонимы
Вы можете создать псевдонимы для этих каталогов и сохранить их в вашем файле ~ / .bashrc .Затем вы можете просто ввести что-то вроде этого:
alias dir1="cd ~/path/to/some/deep/deep/dir1"
alias dir2="cd ~/path/to/some/deep/deep/dir2"
Теперь, когда вы входите в систему, псевдонимы, подобные этим, будут работать из любой оболочки, которая использует файл ~ / .bashrc .
Метод № 2 - Инструменты для создания закладок в каталогах
Взгляните на эти вопросы и ответы под названием Быстрая навигация по каталогам в терминале . Такие инструменты, как autojump или xd - eXtra fast Directory changer , также можно использовать для создания закладок для часто используемых каталогов, чтобы вы могли легко переходить к ним, не вводя длинные пути. .
Контекстно-зависимые псевдонимы
Это может быть что-то, что доступно только тогда, когда вы находитесь в определенном каталоге. Я не знаю, как сделать что-то подобное. Вам нужно будет разработать собственное решение, чтобы облегчить нечто подобное. Сценарий был бы логическим методом для реализации чего-то подобного.
Один из подходов - разработать сценарий, который проверяет, в каком каталоге вы находитесь, перед запуском. Если это не указанный каталог, он просто выйдет из системы. В противном случае это продолжалось бы. Это также может быть реализовано как функция в Bash.
Если сценарий A выполняет что-то еще, то эта программа не наследует определения функций. В Bash есть непонятная функция для экспорта функций через среду. В основном это было неизвестно, пока в реализации не обнаружилась уязвимость. Если вы действительно хотите, вы можете экспортировать функции с помощью export -f, но лучше просто определить функции, которые вы хотите использовать, вместо того, чтобы полагаться на эти функции, присутствующие в среде.
Как уже объяснял RalfFriedl, может ли это иметь какое-то влияние, зависит от того, что на самом деле выполняется внутри исходного скрипта. Поскольку вы не сообщили нам содержание этого сценария, мы никак не можем сказать, повлияет это или нет.
В любом случае, я бы счел плохим замыслом делать такой тип проверки во вторых скриптах. Исходные сценарии должны быть написаны таким образом, чтобы они были идемпотентными. -Мне должно быть разрешено использовать исходный код сценария так часто, как я хочу, без каких-либо штрафов.
Есть несколько вещей, которые мы хотим, чтобы «случилось только один раз». Типичным случаем является добавление чего-либо, например, PATHили LD_LIBRARY_PATH. Если мы будем использовать скрипт несколько раз, путь будет становиться все длиннее и длиннее. Если мы хотим этого избежать, защита должна идти в исходный скрипт, а не в исходный. Шаблон, который я часто использую, выглядит следующим образом:
# Put /foo/bar on top of PATH
: ${_src_xyz_version:=1}
if [[ ${_SRC_XYZ:=0} != $_src_xyz_version ]]
then
export _SRC_XYZ=$_src_xyz_version
export PATH=/foo/bar:$PATH
fi
В этом случае, после того как PATH был расширен, повторный запуск скрипта в моем процессе или любом подпроцессе -не изменяет PATH снова, если только процесс явно не изменяет запрос, выполнив а
export _SRC_XYZ=0