Исходное сообщение
"Посоветуйте, чем в шелл разбирать _длинные_ аргументы скрипта?" Отправлено Licha Morada, 04-Май-20 21:38
> Оказалось, команды три (Bash, BSD, GNU), и две с одинаковым именем (у > BSD и GNU), и из двух с одинаковым именем одна только > работает с длинными именами - https://stackoverflow.com/questions/402377/using-getopts-to-... О как. >> Когда я путаюсь в аргументах своих скриптов, то начинаю задавать параметры через >> переменные окружения. > Глобальные переменные в коде труднее проследить. Смотря как использовать. Если читать переменные окружения из тех мест где понадобится (откуда попало), то да. Если их считывать, проверять на достаточность и непротиворечивость, выставлять все необходимые внутренние флаги в самом начале выполнения, примерно там-же где иначе проводился бы парсинг аргументов, то разница незначительна. > Цель - разворачивать конфигурацию на минимальной системе. Можно задавать переменные окружения в отдельном конфигурационнном файле и вызывать его из скрипта. Можно генерировать уникальный скрипт для каждого развёртывания, с конфигурационными переменными в его-же начале и повторяющемся телом. Не забывая все валидации и проверки при выполнении. Подобную задачу решаем. Типичное выполнение в 2 приёма. Сначала по SCP заливаем несколько файлов, потом по SSH запускаем выполнение. Пишем лог на удалённой машине и паралельно ловим STDOUT от SSH. Например, скрипт первым делом проверяет, на правильной ли машине его запустили и ругается если не. Вообще, 90% кода может быть проверками. Такой недо-Ansible без зависимостей. Это не столько конкретный совет для вашего случая, сколько опции которые могли бы подойти.

Ваше сообщение
Имя*:
EMail:	Для отправки новых сообщений в текущей нити на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>> Оказалось, команды три (Bash, BSD, GNU), и две с одинаковым именем (у >> BSD и GNU), и из двух с одинаковым именем одна только >> работает с длинными именами - https://stackoverflow.com/questions/402377/using-getopts-to-process-long-and-short-command-line-options > О как. >>> Когда я путаюсь в аргументах своих скриптов, то начинаю задавать параметры через >>> переменные окружения. >> Глобальные переменные в коде труднее проследить. > Смотря как использовать. > Если читать переменные окружения из тех мест где понадобится (откуда попало), то > да. > Если их считывать, проверять на достаточность и непротиворечивость, выставлять все необходимые > внутренние флаги в самом начале выполнения, примерно там-же где иначе проводился > бы парсинг аргументов, то разница незначительна. >> Цель - разворачивать конфигурацию на минимальной системе. > Можно задавать переменные окружения в отдельном конфигурационнном файле и вызывать его > из скрипта. > Можно генерировать уникальный скрипт для каждого развёртывания, с конфигурационными переменными > в его-же начале и повторяющемся телом. Не забывая все валидации и > проверки при выполнении. > Подобную задачу решаем. Типичное выполнение в 2 приёма. Сначала по SCP заливаем > несколько файлов, потом по SSH запускаем выполнение. Пишем лог на удалённой > машине и паралельно ловим STDOUT от SSH. Например, скрипт первым делом > проверяет, на правильной ли машине его запустили и ругается если не. > Вообще, 90% кода может быть проверками. Такой недо-Ansible без зависимостей. > Это не столько конкретный совет для вашего случая, сколько опции которые могли > бы подойти.
	Введите код, изображенный на картинке: