シェルスクリプトのユーザー構成。ベストプラクティス？

ユーザーが設定する必要のあるいくつかの変数を含むシェルスクリプトを作成しています。おそらく一連の質問をすることで、スクリプトをダウンロードして構成するためのインストーラーがあります。問題のスクリプトは、他の開発者を対象としています。

これは、いくつかの方法で実装できます。

1. スクリプト自体でプレースホルダーを使用し、sedインストール中にそれらを置き換えるために使用します（/programming/415677/how-to-replace-placeholders-in-a-text-fileのようなもの）

   • 長所：すべての変数定義はスクリプト内に含まれています。スクリプトを手動でダウンロードし、インストーラーよりもエディターを好むユーザー向けに変数を構成するのは簡単です。

   • 短所：インストーラーを使用して変数を設定し直すと、変数を再構成するのは困難です。エラーが発生しやすい、より複雑な正規表現を作成しない限り。

2. configファイルを使用します。基本的に、割り当てのある別のシェルスクリプトを使用sourceして、それを使用します。（そして、おそらくそれを配置し~/.scriptnameますか？メインスクリプトはにコピーされます/usr/local/bin）

   • 長所：スクリプトの再構成は簡単です。メインスクリプトからそれを行うためのパラメータを追加することもできます（おそらく最初のソリューションでも動作しますが、それ自体からスクリプトを編集することは非常に良い考えのようには聞こえません）

   • 短所：スクリプトは2つのファイルに依存するようになり、ユーザーは構成ファイルを作成するためにインストーラーを実行する必要があります。これは、構成ファイルが存在しない場合に構成ファイルを自動生成することで解決できます。ただし、外部の構成ファイルを見つけることは、スクリプトをダウンロードし、編集し、それを実行したいだけのユーザーにとっては依然として面倒です。

また、インストール後にユーザーが構成を管理する方法に関するいくつかのオプション：

1. 
   $ myscript config server.host example.org $ myscript config server.proxypath / home / johndoe / proxyのようなGit $ myscript config server.httppath / home / johndoe / web

2. Interactive
   $ 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

これを行う他の方法はありますか？
ベストプラクティス、エレガントなものはありますか？

私は健全なプログラムに何を期待しますか（シェルスクリプトかどうか）：

• 私は今まで決してそれを構成するために実行可能ファイルを変更する必要がありません。これはOSカーネルではありません。
• コマンドラインを使用して任意の設定を渡すことができます。これは、合理的なデフォルトを持たないすべての情報にとって必須です。唯一の例外は、インタラクティブな入力が必要なパスワードです。
• オプションで、環境変数を使用して設定を渡すことができます。
• 設定を構成ファイルに書き込むことができます。このファイルは、既知の名前で存在する場合、または上記の2つの方法を使用して明示的に指定されている場合に使用されます。
• 構成ファイルは、コマンドラインとまったく同じ設定名と構文を使用します。

さまざまな構成オプションを使用して複雑なスクリプトを作成する必要がある場合、PythonをargparseおよびConfigParserライブラリと共に使用します。これらは実装に役立ちますが、プロセスはすべてのシェルスクリプトに適用されます。

1. 構成ファイルを探します。存在する場合は、その設定を辞書/ルックアップテーブルに読み込みます。
2. 名前付きコマンドライン引数を解析します。指定された各引数について、構成ファイルからロードされた値が存在する場合は、オーバーライドします。configではなくコマンドラインで渡されない引数については、デフォルトを使用します。
3. スクリプトのメイン関数を実行します
4. 構成ファイルが存在しない場合は、渡された値やデフォルト値を書き込みます。

私の好みは、スクリプトを繰り返し使用する場合、設定ファイルに優先オプションを保持することですが、コマンドライン引数はすべてオーバーライドします。初めて実行するときに、これらのパラメーターを使用して構成ファイルを作成します。構成ファイルを共有し、コードリポジトリにコミットできます。

私の最近のケースで[DEFAULT]は、構成ファイルの上部にあるセクションにデフォルトを記述し、それぞれの「環境」に適切なオーバーライドを持つセクションがありました。「環境」は、スクリプトへの最初の名前のないパラメーターです。そのため、この場合、パラメーターは組み込みのデフォルト -> config file default- > config file section value- > command-line parameterとして選択されます。追加のコマンドラインパラメーターは、既存の構成を最新の実行の値で上書きするオプションを提供します。この設定ファイルは現在のディレクトリに書き込まれるため、プロジェクトごとに適用され、残りのコードでコミットできます。同じプロジェクトをチェックアウトする他の人は、同じ構成で開始されます。

プレースホルダーを編集するとエラーが発生しやすくなります。

構成ファイルを使用して行きます。

依存関係についての懸念は妥当ですが、単一のファイルで構成されるツールをあまりにも多く使用したことを覚えていません。理論的には正しいですが、実際にはまったく問題ないはずです。

第三の選択肢は、設定ソフトウェアを作ることである書き込み選択オプションとパラメータに固有の新しいテーラードバージョンを。もちろん、これを書いてテストするのは難しいかもしれません:)