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


13

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

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

  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

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


2
Я не сумніваюся, що ви можете написати скрипт оболонки, який все це робить, але питання полягає в тому, чому ви хочете написати щось таке складне, як це вимагає інсталятор у скрипті оболонки. У будь-якому разі подивіться, як система конфігурації ядра Linux управляє своїм файлом конфігурації.

Добре. Сценарій «інсталятор» завантажуватиме лише справжній сценарій, копіює його у потрібне місце та задає низку питань щодо конфігурації (3-4 змінні). Таким чином я можу надати користувачам єдиний командний рядок, розбиваючи сценарій встановлення та передаючи його в / bin / sh. З іншого боку, я міг пропустити інсталятор і просто додати параметр «встановити» до основного сценарію. Можливо, краще рішення, як ви думаєте?
Charlie Rudenstål

"але питання полягає в тому, чому ви хочете написати щось таке складне", ось розглянутий сценарій: github.com/charlie-rudenstal/depo Я намагаюся зменшити кількість кроків, які потрібно виконувати новим користувачам, особливо під час установка. Ми також намагаємось зробити автоматичне налаштування сервера автоматичним.
Charlie Rudenstål

Відповіді:


6

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

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

Чудова порада. Це був би ваш уподобаний наказ? (1) Перевірка переданих налаштувань у командному рядку (2) Перевірка параметрів у .scriptnameConfig у тому самому каталозі (3) Перевірка параметрів у змінній середовища (4) Перевірка налаштування у .scriptnameConfig у ~ / .scriptnameConfig (5) Використання за замовчуванням налаштування
Чарлі Руденстоль

"Конфігураційний файл використовує ті самі імена параметрів і синтаксис, що і командний рядок." - Як це має виглядати? Я збирався використовувати синтаксис призначення для звичайних скриптів оболонки: SETTING = VALUE. Не вдалося б команді, як синтаксис, відчувати себе трохи дивним всередині файлу конфігурації?
Charlie Rudenstål

Подивіться, як mountабо sshдозволяють використовувати той самий синтаксис у командному рядку та в config. Вам не потрібно повністю копіювати синтаксис командного рядка; замість '--foo = bar' ви можете використовувати 'foo = bar'. Якщо ви використовували "BarOption: Foo", це було б набагато менш зручно: потрібно пам’ятати, якщо випадок значущий, яке ключове слово прийняте у файлі та яке в командному рядку, і неможливість скопіювати та вставити робочу команду рядок у конфігураційний файл із лише косметичним редагуванням.
9000

3

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

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

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

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


"Додатковий параметр командного рядка дає можливість замінити існуючий конфігурацію значенням останнього запуску." Це цікавий підхід. Зручний спосіб поєднання параметрів з конфігурацією.
Charlie Rudenstål

+1, також я рекомендую встановити параметри за замовчуванням у default.configфайлі, розташованому в тому самому каталозі, що і сценарій, а потім шукати конфігураційний файл у, ~/.scriptnameщоб перекрити ці значення. Таким чином, кожне значення має дійсне значення за замовчуванням і його легше підтримувати.
Аарон

2

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

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

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

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.