~/.bashrc私のBashがインタラクティブに使用するのに役立つだけでなく、スクリプト（エイリアス、関数、変数など）にも役立つ幅広いカスタマイズ機能があるとします。私はすべてのスクリプトでこの機能を使用できることを願っているのでBASH_ENV（~/.bashrcこれを行うことができるようです）
私の質問はこれに問題がありますか？
- 1つの問題は、私が使用しているサードパーティのシェルスクリプトが私と同じように機能できることです
~/.bashrc。しかし、とにかく使用する前に検討するので、管理可能な問題だと思います（またはGithub Starsの難解な統計のようなものを盲目的に信頼して安全だと思います）。BASH_ENV誤動作する可能性のあるスクリプトを削除するには、時々身体を下げてください。 - もう一つの問題はスピードですが、正直なところ、私は
~/.bashrcそれほど重くないので、スピードが必要な場合はシェルスクリプトを使用しません。 - もう一つの問題はセキュリティです。しかし、私がいくつかのsetuidまたは特権的地位を持って悪意のあるスクリプトを実行している場合、私はすでにYOLOライフスタイルを生きています
~/.bashrc。 - もう一つの質問は、純粋主義者の観点から見ると、私の
~/.bashrcファイルを2つのファイル、つまり対話型使用のためのファイルとスクリプト用のファイルに分割し、対話型ファイルです。しかし、その漠然とした純粋さを超えて、あまりにも少ない努力にあまりにも多くの努力を注ぐように聞こえます。 - もう一つの問題は移植性ですが、私はほとんど直接スクリプトを書いています。後で他の人と共有したい場合は、一般化することはそれほど難しくありません。最悪の場合は、
~/.bashrc使用している機能が何でも自動的にインライン化されるようにスクリプトを作成できます。 NPの問題ではないようです。 - 私の非標準機能の利点を享受できるスクリプトは、
~/.bashrcそのようなスクリプトを最初に別の言語で書く必要があることを示唆しているので、私のアプローチに欠陥があると主張するかもしれません。 - 一方、Unix / Linuxの哲学は単純な標準セットではなく、環境をニーズに合わせて調整するツールセットなので、できない理由はありません。
答え1
IMO、いいえ、これは良い考えではありません。
これを使用するすべてのスクリプトの上部に関数と変数ライブラリを明示的にインポートすることをお勧めしますexpand_aliases（エイリアスは、シェルオプションが設定されていない限り、非対話型シェルでは機能しません）。これにより、破損する危険性がなくなります（大声で、明らかにまたはより悪くは微妙に）、システム内の数百または数千の既存のスクリプトの1つです。
しかし、いつものように、最終的なルールは次のとおりです。これはあなたのシステムであり、必要に応じてこれを破ることができます。