Куда поместить сценарии обертки?
Все программы получают массив строк как его аргументы. В C++ аргументы argv параметр main функция. Первый элемент того массива является названием программы, другие - аргументы, что Вы передаете.
$ cat foo.cpp
#include <iostream>
int main (int argc, char *argv[]) {
for (int i = 1; i < argc; i++)
std::cout << argv[i] << std::endl;
return 0;
}
$ g++ -o foo foo.cpp
$ ./foo hello world
hello
world
Забудьте о всяких обертках:-)
Все, что вам нужно, это .файл (точечный файл) с параметрами конфигурации пользователя в директории $USER. Вы можете иметь один в /etc для системных опций конфигурации также.
Заставьте ваш скрипт проверить наличие этих .fils (dot file) и, если они существуют, используйте их.
HTH, .
Вы могли использовать aliases или functions
Учитывая общий сценарий $HOME/bin/foo который нужно назвать по-разному, приняв оболочку bash:
Псевдонимы
# ~/.bashrc
alias foo1="$HOME/bin/foo -a -b"
alias foo2="$HOME/bin/foo -c -d"
Функции
# ~/.bashrc
foo1() { $HOME/bin/foo -a -b; }
foo2() { $HOME/bin/foo -c -d; }
export -f foo1 foo2
export -f делает функции доступными в среде, для других сценариев выполненный от Вашей оболочки. Таким образом, Вы могли сделать сценарий foo_all выполните функции foo1 и foo2 без потребности определить их в сценарии.
Дополнительное примечание
Я полагаю, что традиционный путь ко многим состоит в том, чтобы вставить общие сценарии /usr/local/bin/ и помещенный Ваши обертки как обычные сценарии в $HOME/bin/.
Я полагаю, что необходимо абстрагировать еще 1 слой, так, чтобы Вы закончили с этим видом шаблона.
GenericName
calls -> Architecture_or_Server_or_Domain_or_User_specific
calls -> AllArchServer Script
Пример с помощью резервного копирования
do_machine_backup одно имя людей для использования (выполненный, добавьте к заданиям крона и т.д.),
Это - задача, к тренировке, в/на / какой среде/сервере (возможно, пользователь) это выполняется. Скажите, что у Вас есть 3 среды dev/test/prod, это могло разработать это и затем назвать сценарий Environment_Specific.
do_dev_machine_backup -type user | db | web
do_test_machine_backup ...
do_prod_machine_backup ...
or
do_centos_machine_backup -env dev|test|prod ...
...
Это разрабатывает знание домена/среды, который является backup_host, что, чтобы быть поддержанным, который ключи использовать, куда файлы журнала должны пойти и т.д.
do_gen_machine_backup <src dir> <dst host> dst dir> <host_key> ... many args
Я сделал бы эти сценарии (не псевдонимы или функции), перепутывание его (имеющий обоих) будет только служить для создания его более сложным для отлаживания/разрабатывания/поддержания, как это разрабатывает. Вы только сохраняете миллисекунды, сравнивают это с частотой, Вы используете их и продолжительность времени выполнения сценариев, она, вероятно, сделает это незначительным, что это функции/псевдонимы и не сценарии.
Я положил бы все на одно место, где когда-либо Вы хотите, но один верхний уровень, это делает установку нового сервера легкой, установите один каталог и дополнительно, добавьте один каталог к пути. например, /usr/local/CompanyShortName и отсюда, можно расшириться в зависимости от требований теперь и будущего ./bin ./sbin/ ./config ./keys ...
Трудно быть конкретным, таким образом, мои предложения были небольшим дженериком, надо надеяться, некоторые принципы установки среды прибывают через и могут быть фруктами для дальнейших комментариев.