Ubuntuのデフォルトの〜/ .profile source〜/ .bashrcはなぜですか？

これらは、~/.profile13.10に付属の在庫の内容です（コメント行は削除されています）。

if [ -n "$BASH_VERSION" ]; then
    if [ -f "$HOME/.bashrc" ]; then
    . "$HOME/.bashrc"
    fi
fi

if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi

これはDebianから継承されていますが、Canonicalがそれを維持することにしたのはなぜですか？私の知る限り、これは標準的な* nix方式ではなく、これが発生しなかったさまざまなシステムを見てきましたので、それらには正当な理由があったに違いないと思います。これにより、ユーザーが~/.bashrcソースを取得することを想定していないログインシェルを実行するとき（たとえば、マシンに投入するときなど）に予期しない動作が発生する可能性があります。

私が考えることができる唯一の利点は、ユーザーを多くのスタートアップファイルと混同せず、ユーザーが.bashrc単独で編集し、シェルタイプに関係なく読み取りできるようにすることです。ただし、ログインと対話型シェルで異なる設定を使用すると便利な場合が多いため、これは疑わしい利点です。また、ログインシェルはグラフィカル環境で実行されないことが非常に多く、これらのファイルに設定した内容によっては、エラーや警告、問題が発生する可能性があります。

それでは、なぜUbuntuはこれを行うのですか、何が欠けていますか？

これはDebianからのアップストリームの決定です。その理由は、この非常に素晴らしいwiki投稿で説明されており、以下はその抜粋です。エグゼクティブサマリーは、「GUIログインと非GUIログインが同じように機能することを保証するため」です。

例としてxdmを取り上げましょう。pierreはある日休暇から戻ってきて、システム管理者がDebianシステムにxdmをインストールしたことを発見します。彼は正常にログインし、xdmは.xsessionファイルを読み取り、fluxboxを実行します。間違ったロケールでエラーメッセージが表示されるまで、すべては問題ないようです。彼は.bash_profileのLANG変数をオーバーライドし、xdmは.bash_profileを読み取らないため、彼のLANG変数はfr_CAではなくen_USに設定されます。

現在、この問題の単純な解決策は、「xterm」を起動する代わりに、「xterm -ls」を起動するようにウィンドウマネージャーを構成できることです。このフラグは、通常のシェルを起動する代わりに、ログインシェルを起動する必要があることをxtermに伝えます。この設定では、xtermは/ bin / bashを生成しますが、引数ベクトルに「-/ bin / bash」（または「-bash」）を挿入するため、bashはログインシェルのように機能します。これは、彼が新しいxtermを開くたびに、/ etc / profileと.bash_profile（組み込みのbash動作）を読み取り、次に.bashrc（.bash_profileがそうするように指示するため）を読み取ることを意味します。これは最初はうまくいくように見えるかもしれません-彼のドットファイルは重くないので、彼は遅延に気づきさえしません-しかし、より微妙な問題があります。彼はまた、fluxboxメニューから直接Webブラウザーを起動し、また、WebブラウザーはfluxboxからLANG変数を継承しますが、これは現在、間違ったロケールに設定されています。したがって、彼のxtermは問題なく、彼のxtermから起動されたものは問題ないかもしれませんが、彼のWebブラウザーは依然として間違ったロケールのページを提供しています。

それでは、この問題の最良の解決策は何ですか？普遍的なものは本当にありません。より良いアプローチは、.xsessionファイルを次のように変更することです。

[ -r /etc/profile ] && source /etc/profile
[ -r ~/.bash_profile ] && source ~/.bash_profile
xmodmap -e 'keysym Super_R = Multi_key'
xterm &
exec fluxbox

これにより、.xsessionスクリプトを解釈しているシェルは、xmodmapまたはxtermを実行するか、ウィンドウマネージャーを「実行」する前に、/ etc / profileおよび.bash_profileが存在し、読み取り可能な場合、それらを読み取ります。ただし、このアプローチには1つの潜在的な欠点があります。xdmでは、.xsessionを読み取るシェルは制御端末なしで実行されます。/ etc / profileまたは.bash_profileのいずれかが端末の存在を前提とするコマンド（「fortune」や「stty」など）を使用する場合、それらのコマンドは失敗する可能性があります。これが、xdmがデフォルトでこれらのファイルを読み取らない主な理由です。このアプローチを使用する場合は、「ドットファイル」内のすべてのコマンドが、端末がないときに安全に実行されることを確認する必要があります。

これはUbuntuの標準的な動作で~/.bashrcあり、ユーザーレベルのインタラクティブシェルごとの起動ファイルです。あなたは、端末を開くと、基本的には、開始非ログイン、インタラクティブシェル 読み込み~/.bashrcとの内容~/.bashrcGETソース化し、現在のシェル環境にエクスポートします。現在のシェルでユーザー定義のシェル変数と関数をすべて取得するのに役立ちます。また、このような行を見つけることができます

if [ -f ~/.bash_aliases ]; then
    . ~/.bash_aliases
fi

現在のシェル環境でユーザー定義のエイリアスを取得します。

これは、優れたユーザーエクスペリエンスを提供するためにも重要です。例えば、1は、プロキシ資格情報を格納することができ.bashrc、それが調達を取得しない限り、ターミナルアプリケーション（のいずれすなわち、ping、wget、curl、lynxなど）が正常に動作しません。または、ターミナルを開くたびにプロキシ認証情報を提供する必要があります。

Ubuntuのデフォルトに加え.bashrcて、多くのユーザーフレンドリーなエイリアス（カラー化された出力用lsおよびgrep印刷用）、さまざまなシェル変数の多くの新しい定義が含まれ、ユーザーエクスペリエンスが向上します。

ただし、ssh login、または仮想コンソールでのログインの場合、基本的には対話型ログインシェルを取得します。シェル開始ファイルは~/.profileです。したがって、ソース~/.bashrcを使用しない限り、.bashrc。それがUbuntuのデフォルト~/.profileソースです~/.bashrc

避けるべきケース

• あなたは、ソースすることはありません~/.profileフォームの内部を~/.bashrc同時に~/.bashrcから供給されています~/.profile。それは状況の無限ループを作成し、その結果、Ctrl+を押さない限り、ターミナルプロンプトは中断されますC。そのような状況では、~/.bashrc

-xを設定

次に、ターミナルを開いたときにファイル記述子が停止していることがわかります。