Файлы оболочки, ссылающиеся на другие файлы оболочки и лучший способ их вызова

Question

Так что я очень хотел спросить об этом, но не хотел рисковать потерей репутации из-за этого, однако на данный момент мне действительно нужен какой-то прямой вклад. Я новичок Linux, использующий Raspberry Pi для настройки сервера LAMP, и мне нравится создавать файлы оболочки для всех моих команд установки, но мне также нравится сохранять модульность, например:

#!/bin/sh
#LAMPinstall.sh
./apacheinstall.sh
./mysqlinstall.sh
./phpinstall.sh

Я привык к кодированию сред, где такие вызовы тривиальны, но очевидная проблема с этим сценарием в том, что он требует, чтобы текущий рабочий каталог был каталогом сценария на момент вызова.

Я много сделал Linux -specifi c чтение по абсолютным или относительным путям, выбор источника по сравнению с вызовом, bash по отношению к оболочке и различные методы для указания пути сценария в качестве решения для вызовов относительного пути вне CWD, но на В конце дня я не приблизился к решению, к которому чувствую себя хорошо, и, возможно, никогда не буду. На данный момент я доволен использованием абсолютных путей, хранящихся в переменной, таких как:

#!/bin/sh
#LAMPinstall.sh
thisdir=/path/to/scripts
${thisdir}/apacheinstall.sh
${thisdir}/mysqlinstall.sh
${thisdir}/phpinstall.sh

, хотя мне придется модифицировать скрипт при каждом изменении пути.

Так Мой вопрос - скорее вопрос передового опыта, чем просьба о решении конкретной проблемы (хотя это конкретная проблема c), чтобы охватить следующие всего вместо статей и вопросов, о которых я читал каждая отдельная часть:

1. Это плохая идея, чтобы организовать вызовы сценариев оболочки, как я использую?
2. Это плохая идея, чтобы привести путь сценария используя что-то вроде $(dirname "$0"). Если да, то как иначе вы бы поддерживали организацию нескольких файлов оболочки?
3. При рассмотрении таких вопросов, как # 2, важно ли учитывать все возможные варианты использования вашего сценария (т. Е. Если есть подкаталоги и они получены ) кем-то другим, или достаточно сказать: «Этот сценарий должен вызываться, а не только из источника, если кто-то злоупотребляет им, то он на них». Извините, я не могу сформулировать это лучше.

Кроме того, пожалуйста, простите меня, если это наивный вопрос, я просто хотел бы получить некоторую информацию по этому вопросу.

Answer 1

Оболочка не предлагает очень сложных средств для поддержки библиотеки связанных скриптов. Обычные хаки включают в себя ваши предполагаемые или, по крайней мере, подразумеваемые

#!/bin/sh
here="$(dirname "$0")"
"$here"/apacheinstall.sh
"$here"/mysqlinstall.sh
"$here"/phpinstall.sh

или несколько аналогичные

#!/bin/sh
PATH="$(dirname "$0")":$PATH
apacheinstall.sh
mysqlinstall.sh
phpinstall.sh

или требование от пользователя установить подходящую переменную:

#!/bin/sh
: ${LAMP_INSTALL_PATH?Need this variable to be set}
"$LAMP_INSTALL_PATH"/apacheinstall.sh
"$LAMP_INSTALL_PATH"/mysqlinstall.sh
"$LAMP_INSTALL_PATH"/phpinstall.sh

A похожая связанная методика по умолчанию похожа на что-то вроде /usr/local/lib/lampinstall и позволяет пользователю переопределить этот путь подобными средствами.

#!/bin/sh
: ${LAMP_INSTALL_PATH=/usr/local/lib/lampinstall}
"$LAMP_INSTALL_PATH"/apacheinstall.sh
"$LAMP_INSTALL_PATH"/mysqlinstall.sh
"$LAMP_INSTALL_PATH"/phpinstall.sh

Конечно, в любом достаточно современном дистрибутиве реальное решение этой конкретной проблемы - упаковать то, что вам нужно, в пакет и просто установить его. На платформах Debiani sh, например,

sudo apt install -y local-lamp-stuff

, где вам просто нужно создать local-lamp-stuff.deb и иметь его Depends: для пакетов, которые вам необходимы в качестве предварительных условий.