web-dev-qa-db-ja.com

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

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

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はこれを行うのですか、何が欠けていますか？

bashbashrc.profiledesign
30
terdon

これは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がデフォルトでこれらのファイルを読み取らない主な理由です。このアプローチを使用する場合は、「ドットファイル」内のすべてのコマンドが、端末がないときに安全に実行されることを確認する必要があります。

15
terdon

これはUbuntuの標準的な動作です。~/.bashrcは、対話型シェルごとのユーザーレベルの起動ファイルです。基本的にターミナルを開くと、 非ログイン、対話型シェル が起動し、~/.bashrcと~/.bashrcの内容が読み込まれ、現在のシェル環境にソースされ、エクスポートされます。現在のシェルでユーザー定義のShell variablesおよびfunctionsをすべて取得するのに役立ちます。また、このような行を見つけることができます

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

現在のシェル環境でser defined aliasesを取得します。

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

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

しかし、ssh loginまたは仮想コンソールでログインの場合、基本的にインタラクティブなログインシェルを取得します。シェル開始ファイルは~/.profileです。したがって、~/.bashrcを入手しない限り、.bashrcのこれらの有用な設定がすべて失われます。 Ubuntuのデフォルトの~/.profileソース~/.bashrc

避けるべきケース

  • ~/.profileが~/.bashrcからソースされているときに、~/.bashrc内で~/.profileフォームを同時にソースしないでください。それは状況の無限ループを作成し、その結果、あなたがヒットしない限り、端末プロンプトは中断されます Ctrl+C。このような状況では、~/.bashrcに行を入れると
-xを設定

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

2
souravc