Переменные окружения в bash_profile или bashrc?

Question

Я нашел этот вопрос [блог]: Разница между .bashrc и .bash_profile очень полезна, но после просмотра наиболее проголосовавшего ответа (очень кстати) у меня есть дополнительные вопросы. В конце наиболее правильного ответа я вижу следующее утверждение:

Обратите внимание, что вы можете увидеть здесь и там рекомендации, чтобы либо поместить определения переменных среды в ~/.bashrc, либо всегда запускать оболочки входа в систему в терминалах. Оба плохие идеи.

1. Почему это плохая идея (я не пытаюсь бороться, я просто хочу понять)?

2. Если я хочу установить переменную окружения и добавить ее в PATH (например, JAVA_HOME), где это будет лучшим местом для размещения записи экспорта? в ~/.bash_profile или ~/.bashrc?

3. Если ответ на вопрос № 2 ~/.bash_profile, то у меня есть еще два вопроса:

   3.1. Что бы вы поместили в ~/.bashrc? только псевдонимы?

   3.2. Я полагаю, что в оболочке без входа в систему ~/.bash_profile не "подхватывается". Если бы экспорт записи JAVA_HOME был в bash_profile, смог бы ли я выполнить команды javac и java? Будет ли он найти их на пути? Это причина, по которой некоторые сообщения и форумы предлагают установить JAVA_HOME и аналогично ~/.bashrc?

   Заранее спасибо.

Answer 1

В современной системе не так часто встречаются случаи, когда это важно, но это случается. (В частности, если вы используете операции оболочки в vim такие как :r !command или в строке !<motion>command .)

Что бы вы поместили в ~/.bashrc? только псевдонимы?

Вы помещаете в ~/.bashrc вещи, которые не будут наследоваться подоболочками автоматически; в основном это псевдонимы и функции, хотя иногда у вас есть переменные настройки, которые вы не хотите видеть вне оболочки (это очень редко). Можно утверждать, что их нужно каким-то образом экспортировать, но различные экспериментальные попытки натолкнулись на проблемы совместимости с попытками скрыть их в среде и в большинстве случаев были оставлены.

Если я хочу установить переменную окружения и добавить ее в PATH (например, JAVA_HOME), где это будет лучшим местом для размещения записи экспорта? в ~/.bash_profile или ~/.bashrc?

Вы помещаете настройки среды в ~/.bash_profile чтобы им были даны правильные начальные настройки. Иногда вы захотите переопределить их (часто это делается в сложных средах, таких как Matlab или Cadence); если вы поместите параметры среды в ~/.bashrc тогда оболочки, запускаемые из этих сред, потеряют настройки среды, и в результате все может работать неправильно. Это также применимо, если вы используете такие пакеты, как модули, virtualenv, rvm и т.д. Для управления несколькими средами разработки; размещение ваших настроек в ~/.bashrc означает, что вы не можете запустить среду, в которой вы хотите, из вашего редактора, но вместо этого вы будете вынуждены перейти в систему по умолчанию.

Я полагаю, что в оболочке без входа в систему ~/.bash_profile не "подхватывается".

Это правильно; Вы обычно хотите, чтобы начальная оболочка была оболочкой входа в систему, и любые оболочки, запущенные под этой оболочкой, не были оболочками входа в систему. Если начальная оболочка не является оболочкой входа в систему, у вас не будет PATH умолчанию или других настроек (включая ваш пример JAVA_HOME ).

В большинстве сред рабочего стола, запускаемых из диспетчера отображения (то есть подавляющего большинства графических входов в систему), среда рабочего стола не настраивается для всего рабочего стола, поэтому вы вынуждены запускать начальную оболочку в терминалах в качестве оболочки входа в систему. Это вызывает ряд проблем (в частности, то, что PATH и другие доступные для запуска программы, например, панели не настроены должным образом, поскольку панель не является терминалом и не запускается ~/.bash_profile), но является разумным компромиссом, учитывая, что не всегда возможно разумно запустить ~/.bash_profile в неинтерактивной среде в начале сеанса, запускаемого менеджером отображения, в зависимости от его содержимого. Иногда предлагается поместить параметры среды в ~/.bashrc вместо настройки оболочки входа; как обсуждалось выше, это работает до тех пор, пока вам не нужно переопределять эту среду, и вызывает странные поломки, когда вам это нужно.

Недавно я помог диагностировать проблему, подобную этой, в OS X, где пользователь, который поместил настройки в ~/.bashrc затем позже начал использовать rvm и perlbrew, видел странное поведение, потому что среды, созданные этими двумя, были "отменены" ~/.bashrc внутри редакторов и sudo (который в OS X, в отличие от Linux, распространяет $HOME пользователя, чтобы его ~/.bashrc запускался корневой оболочкой). Прежде чем пытаться использовать эти среды, проблем не было; начав использовать их, они были сбиты с толку неожиданной потерей своих настроек.

Answer 2

Честно говоря, в наши дни разница невелика, несмотря на то, что сказал гуру.

проблема заключается в том, что в настоящее время мы входим в систему графически, а не через оболочку входа. Раньше пользователям Unix нравилось видеть короткий отчет о том, что происходит на сервере сразу после входа в систему - затем мы запускаем X из командной строки - для создания этого отчета часто требуется некоторое время (например, 10-20 секунд). и тогда мы не хотим видеть то же самое, когда начинаем, например, xterm. таким образом, разница.

в настоящее время я не думаю, что это различие сейчас важно. Я думаю, что в наши дни, если вы используете bashrc в bash_profile, никто не сможет обвинить вас.

обратите внимание, что это не относится к macos x (каждый запущенный терминал.app является оболочкой входа в систему)

Answer 3

Ну, насчет "Графического логина", это зависит от того, какую * DM вы используете ...

С GDM (Gnome 3.18) у меня есть это:

/ И т.д. / 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

Есть два случая

1. /bin/sh связан с /bin/bash, но работает в режиме «POSIX /Bourne»
2. /bin/sh - это /bin/dash (debian /ubuntu). Быстрее, но с меньшими возможностями (поддержка ShellShock;) )

Таким образом, профиль /bin /sh - это ~ /.profile, а не ~ /.bash_profile, ~ /.zprofile

Этот файл должен использоваться для параметров "независимой от оболочки" , таких как переменные пути и среды.

Никакая исполняемая программа для взаимодействия с пользователем только для входа в систему должна быть, но здесь (проверка почты, состояние и т.д.)

~/.* 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, ИМХО

Но это НЕ РАБОТАЕТ, иногда ...

Например, 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 у вас есть две альтернативы:

1. источник его в ~/.bash_profile или ~/.zprofile (или ~/.zlogin), когда терминал действует как оболочка входа
2. включите скрипт в ~/.bashrc или ~/zshrc

Это означает, что X-клиенты (например, emacs) должны запускаться из оболочки терминала, а не из графической оболочки!

«Я не могу получить никакого удовлетворения ...»