Konfiguracja użytkownika skryptu powłoki. Najlepsze praktyki?

Piszę skrypt powłoki z kilkoma zmiennymi, które powinien skonfigurować użytkownik. Będzie instalator do pobierania i konfigurowania skryptu, prawdopodobnie zadając serię pytań. Skrypt ten jest skierowany do innych programistów.

Można to zrealizować na kilka sposobów:

1. Używaj symboli zastępczych w samym skrypcie i używaj ich seddo zastąpienia podczas instalacji (coś takiego: /programming/415677/how-to-replace-placeholder-in-a-text-file )

   • Plusy: wszystkie definicje zmiennych są zawarte w skrypcie. Łatwo jest pobrać skrypt ręcznie i skonfigurować zmienne dla użytkowników, którzy wolą edytor niż instalator.

   • Wady: trudno jest ponownie skonfigurować zmienne za pomocą instalatora, gdy są już na miejscu. Chyba że utworzę bardziej złożone wyrażenie regularne, które byłoby podatne na błędy.

2. Użyj pliku konfiguracyjnego , w zasadzie innego skryptu powłoki z przypisaniami i użyj, sourceaby go dołączyć. (I prawdopodobnie umieść to w ~/.scriptname? Skrypt główny jest kopiowany /usr/local/bin)

   • Plusy: Łatwo jest zmienić konfigurację skryptu. Można nawet dodać do tego parametr ze skryptu głównego (prawdopodobnie działałoby to również w pierwszym rozwiązaniu, ale sama edycja skryptu nie wydaje się dobrym pomysłem)

   • Wady: skrypt jest teraz zależny od dwóch plików i użytkownik musi uruchomić instalator, aby plik konfiguracyjny został utworzony. Można to rozwiązać automatycznie generując plik konfiguracyjny, jeśli nie istnieje. Ale zlokalizowanie zewnętrznego pliku konfiguracyjnego nadal będzie bardziej kłopotliwe dla użytkowników, którzy chcą pobrać skrypt, edytować go i skończyć z nim.

Ponadto kilka opcji dotyczących sposobu zarządzania konfiguracją przez użytkownika po instalacji:

1. Git jak
   $ myscript config server.host example.org $ myscript config server.proxypath / home / johndoe / proxy $ myscript config server.httppath / home / johndoe / web

2. Interaktywna
   konfiguracja $ myscript
   Wpisz nazwę hosta serwera: example.org
   Wprowadź ścieżkę do serwera proxy na serwerze: / home / johndoe / proxy
   Wprowadź ścieżkę do katalogu http na serwerze: / home / johndoe / web

3. getopts z długimi opcjami
   $ myscript --host example.org --proxypath / home / johndoe / proxy --httppath / home / johndoe / web

4. Prosta
   konfiguracja $ myscript example.org / home / johndoe / proxy / home / johndoe / web

Czy istnieją inne sposoby na zrobienie tego, które można rozważyć?
Jakieś najlepsze praktyki, coś eleganckiego?

Czego oczekiwałbym od rozsądnego programu (skrypt powłoki lub nie):

• I nigdy nie musieli zmieniać wykonywalny tylko skonfigurować go. To nie jest jądro systemu operacyjnego.
• Mogę przekazać dowolne ustawienie za pomocą wiersza polecenia. Jest to konieczne w przypadku każdej informacji, która nie ma rozsądnego domyślnego ustawienia. Jedynym wyjątkiem jest hasło, które wymaga interaktywnego wprowadzania.
• Opcjonalnie mogę przekazać ustawienie za pomocą zmiennej środowiskowej.
• Mogę zapisać ustawienia w pliku konfiguracyjnym, a ten plik zostanie wykorzystany, jeśli będzie występował pod dobrze znaną nazwą lub wyraźnie wskaże na użycie dwóch powyższych metod.
• Plik konfiguracyjny używa tych samych nazw ustawień i składni, co wiersz poleceń.

Kiedy trzeba napisać skomplikowany skrypt z różnych opcji konfiguracyjnych używam Python z argparse i ConfigParser bibliotek. Pomagają w implementacji, ale proces dotyczy dowolnego skryptu powłoki:

1. Poszukaj pliku konfiguracji. Jeśli taki istnieje, przeczytaj wszystkie jego ustawienia w słowniku / tabeli odnośników.
2. Analizuj nazwane argumenty wiersza poleceń. Dla każdego podanego argumentu zastąp wartość załadowaną z pliku konfiguracyjnego, jeśli istnieje. Dla każdego argumentu, który nie został przekazany w wierszu poleceń, a nie w konfiguracji, użyj wartości domyślnej.
3. Wykonaj główną funkcję skryptu
4. Jeśli plik konfiguracyjny nie istnieje, zapisz do niego przekazane i / lub domyślne wartości.

Preferuję, aby plik konfiguracyjny zawierał preferowane opcje, gdy skrypt będzie używany wielokrotnie, ale niech wszystkie argumenty wiersza poleceń zostaną zastąpione. Napisz plik konfiguracyjny przy użyciu tych parametrów przy pierwszym uruchomieniu. Plik konfiguracyjny można następnie udostępnić i zatwierdzić w repozytorium kodów.

W moim ostatnim przypadku zapisałem również wartości domyślne w [DEFAULT]sekcji u góry pliku konfiguracyjnego, a następnie miałem sekcję dla każdego „środowiska” z odpowiednimi zastąpieniami dla każdego. „Środowisko” jest pierwszym nienazwanym parametrem skryptu. Tak więc w tym przypadku parametry są wybierane jako wbudowane domyślne -> domyślny plik konfiguracyjny -> wartość sekcji pliku konfiguracyjnego -> parametr wiersza poleceń . Dodatkowy parametr wiersza poleceń umożliwia zastąpienie istniejącej konfiguracji wartością najnowszego uruchomienia. Ten plik konfiguracyjny jest zapisywany w bieżącym katalogu, więc obowiązuje dla każdego projektu i można go zatwierdzić resztą kodu. Każdy, kto będzie sprawdzał ten sam projekt, zacznie od tej samej konfiguracji.

Edycja symboli zastępczych jest podatna na błędy.

Chciałbym użyć pliku Config.

Twoje obawy dotyczące zależności są uzasadnione, jednak nie pamiętam używania zbyt wielu narzędzi, które składają się z jednego pliku. Teoretycznie masz rację, ale praktycznie powinno być całkiem OK.

Trzecią opcją jest, aby oprogramowanie konfiguracyjne napisać nową wersję, która jest dostosowane do specyficznych wybranych opcji i parametrów. Oczywiście może być trudniej napisać i przetestować :)