Посоветуйте, чем в шелл разбирать _длинные_ аргументы скрипта?, Licha Morada, 20:12 , 04-Май-20 (1)

> Если именя аргумента длинное, то без документации и литературного творчества в коде
> скрипта сразу ясно для чего аргумент.
Когда я путаюсь в аргументах своих скриптов, то начинаю задавать параметры через переменные окружения.
> Getops не умеет работать с длинными именами аргументов. Хочу без магичности и
> волшебности имён в виде одной буквы. Чтобы по имени аргумента было
> чётко ясно для чего аргумент.
Бывает встроенная getopts, а бывает отдельная getopt. Вроде, последняя умеет длинные аргументы.
$ which getopts
$ which getopt
/usr/bin/getopt
> Чем сделать, чтобы как в Python Argparse задать число параметров, группы аргументов
> и т.д. Можно написать "while ; do shift ; done", но
> хочется большего.
Кроме того, возможно, вы приблизились к границе применимости шелл скрипта как инструмента.

Ответить | Сообщить модератору

Посоветуйте, чем в шелл разбирать _длинные_ аргументы скрипта?, And, 20:49 , 04-Май-20 (2)

Посоветуйте, чем в шелл разбирать _длинные_ аргументы скрипта?, Licha Morada, 21:38 , 04-Май-20 (3)

> Оказалось, команды три (Bash, BSD, GNU), и две с одинаковым именем (у
> BSD и GNU), и из двух с одинаковым именем одна только
> работает с длинными именами - https://stackoverflow.com/questions/402377/using-getopts-to-...
О как.

>> Когда я путаюсь в аргументах своих скриптов, то начинаю задавать параметры через
>> переменные окружения.
> Глобальные переменные в коде труднее проследить.
Смотря как использовать.
Если читать переменные окружения из тех мест где понадобится (откуда попало), то да.
Если их считывать, проверять на достаточность и непротиворечивость, выставлять все необходимые внутренние флаги в самом начале выполнения, примерно там-же где иначе проводился бы парсинг аргументов, то разница незначительна.

> Цель - разворачивать конфигурацию на минимальной системе.
Можно задавать переменные окружения в отдельном конфигурационнном файле и вызывать его из скрипта.
Можно генерировать уникальный скрипт для каждого развёртывания, с конфигурационными переменными в его-же начале и повторяющемся телом. Не забывая все валидации и проверки при выполнении.
Подобную задачу решаем. Типичное выполнение в 2 приёма. Сначала по SCP заливаем несколько файлов, потом по SSH запускаем выполнение. Пишем лог на удалённой машине и паралельно ловим STDOUT от SSH. Например, скрипт первым делом проверяет, на правильной ли машине его запустили и ругается если не. Вообще, 90% кода может быть проверками. Такой недо-Ansible без зависимостей.
Это не столько конкретный совет для вашего случая, сколько опции которые могли бы подойти.
Ответить | Сообщить модератору

Посоветуйте, чем в шелл разбирать _длинные_ аргументы скрипта?, Аноним, 02:02 , 14-Май-20 (4)

Посоветуйте, чем в шелл разбирать _длинные_ аргументы скрипта?, Аноним, 02:04 , 14-Май-20 (5)

Посоветуйте, чем в шелл разбирать _длинные_ аргументы скрипта?, Licha Morada, 03:20 , 14-Май-20 (6)
В данном случае, передача данных через переменные окружения рассматривается как альтернатива передачи тех-же данных, но в параметрах командной строки.
Если данных так много, что мы вылезаем за пределы применимости переменных окружения, то мы тем более вылезаем за пределы применимости командной строки и вопрос можно закрывать.
Ответить | Сообщить модератору