web-dev-qa-db-ja.com

bash_profileまたはbashrcの環境変数？

私はこの質問を見つけました[ブログ]： 。bashrcと.bash_profileの違い 非常に便利ですが、最も投票された回答（ちなみに非常に良い）を見た後、さらに質問があります。最も投票された正しい答えの終わりに向かって、私は次のように述べています：

環境変数の定義を〜/ .bashrcに置くか、常にターミナルでログインシェルを起動するかの推奨がこことそこにあることに注意してください。どちらも悪い考えです。

  1. なぜそれが悪い考えなのですか（私は戦うつもりはありません。ただ理解したいだけです）。

  2. 環境変数を設定し、それをPATHに追加する場合（たとえば、Java_HOME）、エクスポートエントリを配置するのに最適な場所はどこですか？ 〜/ .bash_profileまたは〜/ .bashrc？

  3. 質問番号2の答えが〜/ .bash_profileの場合、さらに2つの質問があります。

    3.1。 〜/ .bashrcの下に何を置きますか？エイリアスだけですか？

    3.2。非ログインシェルでは、〜/ .bash_profileが「選択」されていないようです。 Java_HOMEエントリのエクスポートがbash_profileにあった場合、javac＆Javaコマンド？ PATHでそれらを見つけますか？それが、いくつかの投稿やフォーラムがJava_HOMEなどを〜/ .bashrcに設定することを提案する理由ですか？

    前もって感謝します。

bashpathenvironment-variablesbashrc.bash-profile
36
Viriato

最近のシステムでは、重要なケースに遭遇することは特に一般的ではありませんが、それは起こります。 （特に、:r !commandやインライン!<motion>commandフォームなどのvimでシェル操作を使用する場合。）

〜/ .bashrcの下に何を入れますか？エイリアスだけですか？

サブシェルに自動的に継承されないものを~/.bashrcに入れます。これは、ほとんどの場合、エイリアスと関数を意味しますが、シェルの外に表示したくない変数設定がある場合があります（これは非常にまれです）。どういうわけかそれらをエクスポートする必要があると主張することができますが、さまざまな実験的な試みが環境内でそれらを非表示にしようとすると互換性の問題に遭遇し、ほとんど放棄されました。

環境変数を設定し、それをPATHに追加する場合（たとえば、Java_HOME）、エクスポートエントリを配置するのに最適な場所はどこですか？ 〜/ .bash_profileまたは〜/ .bashrcにありますか？

環境設定を~/.bash_profileに入れて、適切な初期設定が与えられるようにします。これらをオーバーライドしたい場合があります（多くの場合、これはMatlabやCadenceなどの複雑な環境で行われます）。環境設定を~/.bashrcに配置すると、それらの環境内から実行されたシェルは環境のカスタマイズを失い、結果として正常に機能しない可能性があります。これは、 modules 、 virtualenv 、 rvm などのパッケージを使用して複数の開発環境を管理する場合にも当てはまります。設定を~/.bashrcに置くと、エディター内から目的の環境を実行できなくなり、代わりにシステムのデフォルトに強制されます。

非ログインシェルでは、〜/ .bash_profileが「選択」されていないようです。

これは正しいです;通常、最初のシェルをログインシェルにして、そのシェルの下で起動したすべてのシェルがログインシェルにならないようにします。最初のシェルがログインシェルでない場合、デフォルトのPATHやその他のさまざまな設定（Java_HOMEの例を含む）はありません。

ディスプレイマネージャーから起動されたほとんどのデスクトップ環境（つまり、グラフィカルログインの大部分）はデスクトップ全体のログイン環境を設定しないため、ターミナルで初期シェルをログインシェルとして実行する必要があります。これはいくつかの問題を引き起こします（特に、パネルが端末ではなく~/.bash_profileを実行していないため、パネルなどから実行されるプログラムで使用できるPATHなどが正しく設定されていません）が、妥当な妥協案です。内容によっては、ディスプレイマネージャーによって開始されたセッションの開始時に、非インタラクティブ環境で~/.bash_profileを正常に実行できるとは限りません。ログインシェルを設定する代わりに、環境設定を~/.bashrcに配置することが推奨される場合があります。上で説明したように、これはその環境をオーバーライドする必要がない限り機能し、doを実行する必要があると奇妙な破損を引き起こします。

私は最近、OS Xでこのような問題を診断するのを手伝いました。~/.bashrcに設定を配置し、その後rvmを使用し始めたユーザーが perlbrew を使用すると、2つの環境によって設定された環境が奇妙な動作をするようになりましたエディター内の~/.bashrcとSudoによって「取り消されました」（OS Xでは、Linuxとは異なり、ユーザーの$HOMEを伝搬して、~/.bashrcがルートシェルによって実行されるようにします）。これらの環境を使用する前は、問題はありませんでした。それらの使用を開始すると、設定が予期せず失われることに戸惑いました。

26
geekosaur

正直なところ、グルが言っていたにもかかわらず、最近はほとんど違いがありません。

この背後にある問題は、現在、ログインシェルではなくグラフィカルにログインしていることです。以前は、UNIXユーザーはログイン直後にサーバーで何が起こっているかについての短いレポートを見たいと思っていました。次に、コマンドラインからXを起動します。これらのレポートは、生成に時間がかかることがよくあります（例：10〜20秒）。そして、私たちは私たちが開始したときに同じことを見たくありません。 xterm。したがって、違い。

最近では、その区別は重要ではないと思います。私は最近、bash_profileでbashrcを入手した場合、誰もあなたを責めることはできないと思います。

これはmacos xには適用されないことに注意してください（開始されたすべてのterminal.appはログインシェルです）

2
bubu

さて、「グラフィカルログイン」については、使用する* DMによって異なります...

GDM（Gnome 3.18）を使用すると、次のようになります。

/ etc/gdm/Xsession

#!/bin/sh   <= *important*

...

# First read /etc/profile and .profile
test -f /etc/profile && . /etc/profile
test -f "$HOME/.profile" && . "$HOME/.profile"
# Second read /etc/xprofile and .xprofile for X specific setup
test -f /etc/xprofile && . /etc/xprofile
test -f "$HOME/.xprofile" && . "$HOME/.xprofile"

そのため、〜/ .profileは/ bin/shではなく/ bin/bashを使用してログイン時にソースを取得します

2つのケースがあります

  1. / bin/shは/ bin/bashにリンクされますが、 "POSIX/Bourne"モードで実行されます
  2. / bin/shは/ bin/dash（debian/ubuntu）です。最速だが機能が少ない（Shellshock support;））

したがって、/ bin/shプロファイルは〜/ .profileであり、〜/ .bash_profile、〜/ .zprofileではありません

このファイルは、パスや環境変数などの "Shell agnostic"設定に使用する必要があります。

[〜＃〜] no [〜＃〜]ログインのみのユーザー操作用の実行可能プログラムはここにあるはずです（メールチェック、フォーチュンなど...）

〜/.* rcは、「インタラクティブ」セッション（エイリアスなど）のみを対象としています。

対話型loginシェルのbashとzshには違いがあります

bashソースは.bash_profileのみですが、zshソースは次の順序です。

  1. 〜/ .zprofile
  2. 〜/ .zshrc
  3. 〜/ zlogin（ここでは〜/ .zshrcで定義されたエイリアスが利用可能です。 "インタラクティブ" + "ログイン"シェルの場合

正しい方法〜/ .bash_profileはここで答えられました：

。bashrcと.bash_profileの違い

if [ -r ~/.profile ]; then . ~/.profile; fi
case "$-" in *i*) if [ -r ~/.bashrc ]; then . ~/.bashrc; fi;; esac

テスト（およびプロファイリング）を有効にするには、これを使用できます

〜/ .bash_profile：

#!/bin/bash

# ------------------------------------------------
export _DOT_BASH_PROFILE_0=`date  --rfc-3339=ns`
# ------------------------------------------------

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

case "$-" in *i*) if [ -r ~/.bashrc ]; then . ~/.bashrc; fi;; esac

# ------------------------------------------------
export _DOT_BASH_PROFILE_1=`date  --rfc-3339=ns`
# ------------------------------------------------

〜/ .zprofile：

#!/bin/zsh

# ------------------------------------------------
export _DOT_ZSH_PROFILE_0=`date  --rfc-3339=ns`
# ------------------------------------------------

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

# no need to source, zsh already handle ~/.zshrc

###case "$-" in *i*) if [ -r ~/.zshrc ]; then . ~/.zshrc; fi;; esac

# ------------------------------------------------
export _DOT_ZSH_PROFILE_1=`date  --rfc-3339=ns`
# ------------------------------------------------

次に、テストするには：

chsh -s /bin/bash

ssh localhost
env

exit

ssh localhost env

ssh -t localhost bash -i -c env


chsh -s /bin/zsh

ssh localhost
env

exit

ssh localhost env

ssh -t localhost bash -i -c env

したがって、RVM/virtualenvは〜/ .profileに移動する必要があります。

しかし、これは機能しない、ときどき...

たとえば、virualenvwrapperは、Xsessionを実行するシェルが「元の」bashである場合にのみ機能します（BASH_VERSIONをエクスポート）

dashシステムを使用している場合、環境変数とパス設定は機能しますが、virualenvwrapper関数定義は機能しません。 POSIXに準拠していません。

スクリプトはエラーを出しませんが、 "workon"定義なしで終了します。

したがって、手元の環境を〜/ .profileで設定して、正しいpython Xから直接開始されたクライアントからの実行を有効にすることができます。

export VIRTUAL_ENV="/home/mike/var/virtualenvs/myvirtualenv"
export PATH="$VIRTUAL_ENV/bin:$PATH"
unset PYTHON_HOME

https://Gist.github.com/datagrok/2199506

https://www.bountysource.com/issues/9061991-setting-up-your-computer-virtualenvwrapper-linux-all

しかし、virualenvwrapperの場合、2つの選択肢があります。

  1. 端末がログインシェルとして機能する場合は、〜/ .bash_profileまたは〜/ .zprofile（または〜/ .zlogin）でソースします。
  2. 〜/ .bashrcまたは〜/ zshrcにスクリプトを含めます

つまり、Xクライアント（emacsなど）は、グラフィカルシェルからではなく、ターミナルシェルから起動する必要があります。

「満足感が出ない…」

1
hute37