最近引っ越しました。魚~から強く打つ。私はすぐにその機能に反していました。しかし、シェル構成に関しては少し圧倒されました。
私が読んで文書、特に初期化部分について、これは次のとおりです。
起動時に、Fishは複数の設定ファイルを評価します。
- .fish で終わるファイルの構成フラグメントは、次のディレクトリにあります。
$__fish_config_dir/conf.d（基本的に、~/.config/fish/conf.d/）- ...
- ユーザーの初期化は通常
~/.config/fish/config.fish...
今、この点は明確に理解されています。 Bashから.bash_globals出てファイルを取り出して、.bash_aliasesFishの構文に基づいて少し書き換えてから入れて、期待どおり~/.config/fish/conf.d/にロードしました。
ところでファイルの内容を見るからconfig.fishそこに入れなければならない内容が一つも浮かびませんね。私が理解したところ、fishはデフォルトで使用されるように設計されているので、HISTCONTROL通常のbash設定（設定など）は必要ありません。これらのファイルは、conf.d/一部のデフォルトスクリプト（.bash_aliasesetcなど.bashrc）でも呼び出されず、自動的にロードされます。
config.fishファイルが好ましいか、必要な特定のユースケースがありますか？conf.d/今までは、単一のファイルが読みやすく、メンテナンス、ホスト間の移動が簡単だと言いたいと思います。従うべき推奨ルールはありますか？ユーザーにより多くの自由を提供することに加えて、そのような多くのレベルの設定を可能にする特別な動機はありますか？
ベストアンサー1
これを行うには、両方にいくつかの妥当な理由があると言いたいと思います。
まず、おそらく最も重要なことは、@Zancheyがコメントで指摘したように、conf.dバージョン2.3.0でサポートが提供されたため、config.fishその時点での削除は画期的な変更になります。
第二に、あなたが言ったように、ユーザーは開始アクションを処理する方法を自由に選択できます。
第二に、ある意味では「抵抗が最も少ない道」でもあります。私はファイルモジュール化に対するあなたの好みにしっかりと同意しconf.d/、私config.fish自身がそれを持っていないのが好きです。ただし、一部の（おそらくほとんどの）最初のユーザーは、基本的に設定を保存する同様の場所fishに慣れています。.bash_profileパラダイムの変化を想像できるいいえ単一のファイル構成は、一部の人々に不快感を与える可能性があります。つまり、config.fish新規ユーザーにシームレスな移行を提供するのに役立ちます。
また、config.fish以前のシェルで既に知っているものとマッピングされているため、新しいユーザーに簡単に説明できます。 〜でもfish よくある質問デフォルトは、これがconfig.fish以前の起動スクリプトと同じであることをユーザーに通知します。私は彼らがconf.d/代替案についても説明し続けたいと思います。
そしてconfig.fishもう一つの小さな利点があります。実行順序がより明確です（つまり、最初から最後まで実行されます）。ファイルは他のファイルと同様に、アルファベット順（またはほとんどの場合全体の結果順序）でconf.d/読み取られます。私の経験では、これはあるファイルが別のファイルの前に実行されるようにするために名前付きタイプconf.d/に依存する必要があることを意味します。00_dependency.fishつまり、これに頼らなければならない人はほとんどいないでしょう。
httpd.conf「ルール」については、多くのディストリビューションがデフォルトの「単一ファイル」を使用して構成ファイル（Apache2など）を設定し、構造を処理し続けることを知っていますconf.d/。この例では、fishキャンセルしました。for conffile in ~/.config/fish/conf.d/*.fish; source $conffile; endconfig.fish