bash_profileまたはbashrcの環境変数?


36

私はこの質問[ブログ]発見した: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に設定することを推奨している理由はそれですか?

    前もって感謝します。

回答:


26

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

〜/ .bashrcの下に何を置きますか?エイリアスのみ?

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

環境変数を設定し、それをPATH(たとえばJAVA_HOME)に追加して、エクスポートエントリを置くのに最適な場所にする場合はどうすればよいですか?〜/ .bash_profileまたは〜/ .bashrc?

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

非ログインシェルでは、〜/ .bash_profileは「ピックアップ」されていないと思います。

これは正しいです; 通常、初期シェルをログインシェルにし、そのシェルの下で起動したシェルをログインシェルにしないでください。初期シェルがログインシェルではない場合、デフォルトPATHやその他のさまざまな設定(JAVA_HOMEサンプルを含む)はありません。

ディスプレイマネージャー(つまり、グラフィカルログインの大半)から起動されたほとんどのデスクトップ環境は、デスクトップ全体のログイン環境を設定しないため、ターミナルで初期シェルをログインシェルとして実行する必要があります。これは多くの問題を引き起こします(特にPATH、パネルは端末ではなく実行されていないため、例えばパネルから実行されるプログラムで利用可能なものなどが適切にセットアップされていないこと~/.bash_profile)。~/.bash_profile内容に応じて、ディスプレイマネージャによって開始されたセッションの開始時に非インタラクティブ環境で正常に実行されます。環境設定を配置することが推奨される場合があります~/.bashrc代わりにログインシェルを設定する代わりに; 上述したように、この作品は長い間、あなたはその環境をオーバーライドする必要はありませんようとして、あなたは一度奇妙な破損の原因とやるそうする必要性を。

私は最近、OS Xでこのような問題を診断するのを手伝いました。~/.bashrcその後、設定を行ったユーザーが使用rvmを開始し、perlbrewが奇妙な動作~/.bashrcをしました。sudo(これはOS X上、Linuxとは異なり、ユーザーを伝播してルートシェルで実行される$HOMEようにしまし~/.bashrcた)。これらの環境を使用する前に、問題はありませんでした。それらを使用し始めると、設定が予期せず失われることに戸惑いました。


1
私は理解していると思う、それをもっと内部化するためにもっと読む必要があるかもしれないが、私は以下を結論づけている。エンタープライズ環境では、グローバルシェルの副作用なしにカスタマイズされたシェルをより細かく制御するために、環境変数を〜/ .bash_profileに入れるのがベストプラクティスです。UbuntuやLinux Mintなどの個人環境では、PATHを適切に設定するために〜/ .bashrc(または/ etc / profileでも)に設定する必要があります。私は正しいですか?
ビリアート

あなたが単なるユーザーであるか開発者であるかということよりも、エンタープライズ環境との関係はあまりありません。以下のようなシステムmodulesrvm開発者向けツールですが、として「開発者」の多少異なる定義のためのMatlabとケイデンスあります。シンプルな開発も、それらを必要としませんが、あなたはルビーやPerl、またはPythonの複数のバージョンに対してテストする必要がある場合、あなたは本当に何かのようにしたいrvmperlbrewvirtualenvそれがすべてまっすぐに保つの周りの助けに(それぞれ)。
ギーコサウルス

2

正直に言うと、最近では第一人者が言わなければならないことにもかかわらず、ほとんど違いはありません。

この背後にある問題は、最近ではログインシェル経由ではなくグラフィカルにログインすることです。過去には、ユーザーはログイン直後にサーバーで何が起こっているかの短いレポートを見たいと思います-それからコマンドラインでXを起動します-これらのレポートはしばしば生成に時間がかかります(例:10-20秒)。そして、例えばxtermを起動したときに同じものを見たくありません。したがって、違い。

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

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


完全に理解しているかどうかは正確にはわかりませんが、職場ではログインシェルであるsshを介してログインすると、bash_profileとbashrcがソースになりますので、その場合は問題ではないと思います。しかし、グラフィカルにログインした場合(それはどういう意味ですか?)個人のubuntuにログインするような?
ビリアート

ここでの@bubuの回答に同意します。~/.bash_profileソースを使用しないセットアップは~/.bashrc、作業が難しく、壊れている場合に対応します。グラフィカルなターミナルアプリは、〜/ .bashrcをソースしてすべての設定をそこに置く方が簡単だということです。
リッチベル

1

「グラフィカルログイン」については、使用する* 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 / bashではなく/ bin / shを使用してログインで取得されます

2つのケースがあります

  1. / bin / sh/ bin / bashにリンクされていますが、「POSIX / Bourne」モードで実行されます
  2. / bin / sh/ bin / dash(debian / ubuntu)です。最速だが機能は少ない(ShellShockサポート;)

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

このファイルは、パスや環境変数などの「シェルに依存しない」設定に使用する必要があります。

NOのログインのみのユーザーとの対話のための実行可能プログラムはしないが、ここでなければならない(メールチェック、占い、など...)

〜/.* rcは、「インタラクティブ」セッションのみを対象としています(たとえば、エイリアス...)

対話型ログインシェルの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、IMHOに入れる必要があります

しかし、これはうまくいきません時には ...

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

あなたが上にある場合はダッシュシステム、環境変数とパスの設定作業が、virualenvwrapperスクリプトはPOSIXに準拠していないため、関数定義がない作業を行います。

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

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

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)はグラフィカルシェルからではなく、ターミナルシェルから起動する必要があることを意味します!

「満足できません...」


systemdでサービスを実行するのとはまったく別の話です。 可能な代替方法としては、ラッパースクリプトの作成、「service」定義ファイルでの環境の定義、 shell ファイルでの環境のダンプが親シェルにあります。物事はなりトリッキーとRVM / virtualenvの...
hute37
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.