Конфігурація користувача сценарію оболонки. Кращі практики?

Я пишу сценарій оболонки з кількома змінними, які повинен налаштувати користувач. Буде встановлена ​​програма для завантаження та налаштування сценарію, можливо, задавши серію запитань. Роздільний сценарій спрямований на інших розробників.

Це може бути реалізовано кількома способами:

1. Використовуйте заповнювачі у самому сценарії та використовуйте sedдля заміни їх під час встановлення (приблизно так: /programming/415677/how-to-replace-placeholders-in-a-text-file )

   • Плюси: всі визначення змінних містяться в сценарії. Завантажити скрипт легко вручну та налаштувати змінні для користувачів, які віддають перевагу редактору над інсталятором.

   • Мінуси: Важко переналаштувати змінні через інсталятор, як тільки вони будуть на місці. Якщо я не створять більш складний регулярний вираз, який був би схильний до помилок.

2. Використовуйте конфігураційний файл , в основному інший скрипт оболонки з призначеннями, і використовуйте sourceдля його включення. (І, можливо, розмістіть його ~/.scriptname? Основний сценарій скопійовано у /usr/local/bin)

   • Плюси: легко налаштувати сценарій. Можна навіть додати параметр для цього з головного сценарію (можливо, він би працював і в першому рішенні, але редагування сценарію від себе не здається дуже хорошою ідеєю)

   • Мінуси: сценарій тепер залежить від двох файлів, і користувачеві потрібно запустити інсталятор для створення конфігураційного файла. Це можна вирішити шляхом автоматичного генерування конфігураційного файлу, якщо такого немає. Але розміщення зовнішнього файлу конфігурації все-таки буде більш громіздким для користувачів, які просто хочуть завантажити скрипт, відредагувати його і зробити це з ним.

Також кілька варіантів щодо того, як керувати налаштуванням повинен користувач після встановлення:

1. Як подібний
   $ myscript config server.host example.org $ myscript config server.proxypath / home / johndoe / proxy $ myscript config server.httppath / home / johndoe / web

2. Інтерактивний
   $ myscript config
   Введіть ім'я хоста сервера: example.org
   Введіть шлях до проксі-сервера на сервері: / home / johndoe / proxy
   Введіть шлях до http-каталогу на сервері: / home / johndoe / web

3. getopts з довгими параметрами
   $ myscript --host example.org - proxypath / home / johndoe / proxy --httppath / home / johndoe / web

4. Простий
   $ myscript config example.org / home / johndoe / proxy / home / johndoe / web

Чи є якісь інші способи зробити це, які ви б розглядали?
Будь-які найкращі практики, щось елегантне?

Що я б очікував від розумної програми (сценарій оболонки чи ні):

• Мені ніколи не доводиться змінювати виконуваний файл, щоб просто його налаштувати. Це не ядро ​​ОС.
• Я можу передавати будь-які налаштування за допомогою командного рядка. Це обов'язково для кожної інформації, яка не має розумного дефолту. Єдиним винятком є ​​пароль, який потребує інтерактивного введення.
• За бажанням я можу передавати налаштування за допомогою змінної середовища.
• Я можу записати налаштування в конфігураційний файл, і цей файл буде використовуватися, якщо він присутній під відомим іменем або явно вказується на використання двох вищевказаних методів.
• Конфігураційний файл використовує ті самі імена параметрів і синтаксис, що і командний рядок.

Коли мені потрібно написати розроблений сценарій з різними параметрами конфігурації, я використовую Python з бібліотеками argparse та ConfigParser . Вони допомагають у реалізації, але процес стосується будь-якого сценарію оболонки:

1. Шукайте конфігураційний файл. Якщо така існує, прочитайте будь-які її налаштування в словнику / таблиці пошуку.
2. Аналіз аргументів командного рядка. Для кожного наданого аргументу замініть значення, завантажене з конфігураційного файлу, якщо він існує. Для будь-якого аргументу, який не передається в командному рядку і не в конфігурації, використовуйте за замовчуванням.
3. Виконати основну функцію сценарію
4. Якщо конфігураційного файлу не існує, запишіть у нього передані та / або значення за замовчуванням.

Моя перевага полягає в тому, щоб конфігураційний файл містив бажані параметри, коли сценарій буде використовуватися неодноразово, але нехай будь-які аргументи командного рядка перекривають. Напишіть конфігураційний файл, використовуючи ці параметри під час першого запуску. Конфігураційний файл може бути наданий спільному коду та переданий у сховище коду.

У моєму останньому випадку я також писав параметри за замовчуванням до [DEFAULT]розділу у верхній частині файлу config, а потім мав розділ для кожного "середовища" з відповідними переопрацюваннями для кожного. "Середовище" - це перший неназваний параметр сценарію. Тож у цьому випадку параметри вибираються як вбудований за замовчуванням -> конфігураційний файл за замовчуванням -> значення розділу розділу конфігураційного файлу -> параметр командного рядка . Додатковий параметр командного рядка дає можливість замінити існуючий конфігурацію значенням останнього запуску. Цей файл конфігурації записується в поточний каталог, тому він застосовується для кожного проекту і може бути зроблений з рештою коду. Усі, хто перевіряє той самий проект, потім почнуть з тієї ж конфігурації.

Редагування заповнювачів схильне до помилок.

Я б пішов з використанням файлу Config.

Ваша стурбованість залежністю справедлива, однак я не пам’ятаю, щоб використовувати занадто багато інструментів, що складаються з одного файлу. Отже, теоретично ви праві, але практично це повинно бути цілком нормально.

Третій варіант , щоб зробити програмне забезпечення конфігурації написати нову підігнані версію, яка специфічна для обраних опцій і параметрів. Це може бути складніше написати та перевірити звичайно :)