Переменные среды в bash_profile или bashrc?
Я нашел этот вопрос [блог]: Разница между .bashrc и .bash_profile очень полезна, но после того, как я увидел ответ, получивший наибольшее количество голосов (кстати, очень хороший), у меня возникли дополнительные вопросы. Ближе к концу правильного ответа, получившего наибольшее количество голосов, я вижу следующее утверждение:
Обратите внимание, что вы можете видеть здесь и там рекомендации либо поместить определения переменных среды в ~ / .bashrc, либо всегда запускать оболочки входа в систему в терминалах. Оба плохие идеи.
Почему это плохая идея (я не пытаюсь бороться, я просто хочу понять)?
Если я хочу установить переменную среды и добавить ее в PATH (например, JAVA_HOME), где лучше всего разместить экспортную запись? в ~ / .bash_profile или ~ / .bashrc ?
Если ответ на вопрос номер 2 - ~ / .bash_profile , у меня есть еще два вопроса:
3.1. Что бы вы поместили в ~ / .bashrc ? только псевдонимы?
3.2. Я считаю, что в оболочке без входа в систему ~ / .bash_profile не «подбирается». Если экспорт записи JAVA_HOME был в bash_profile, смогу ли я выполнять команды javac и java ? Найдет ли он их на ПУТИ? Это причина, по которой некоторые сообщения и форумы предлагают установить JAVA_HOME и тому подобное в ~ / .bashrc ?
Заранее спасибо.
Ответы
В современной системе не особо часто встречаются случаи, когда это имеет значение, но такое случается. (В частности, если вы используете операции оболочки в vimтакой как :r !commandили встроенной !<motion>commandформе.)
Что бы вы поместили в ~ / .bashrc? только псевдонимы?
Вы вставляете вещи ~/.bashrc, которые не будут унаследованы подоболочками автоматически; в основном это означает псевдонимы и функции, хотя иногда у вас есть настройки переменных, которые вы не хотите видеть за пределами оболочки (это очень редко). Можно было бы утверждать, что их нужно как-то экспортировать, но различные экспериментальные попытки натолкнулись на проблемы совместимости с попытками скрыть их в среде, и в основном от них отказались.
Если я хочу установить переменную среды и добавить ее в PATH (например, JAVA_HOME), где лучше всего разместить экспортную запись? в ~ / .bash_profile или ~ / .bashrc?
Вы вводите параметры среды ~/.bash_profileтак, чтобы им были предоставлены разумные начальные параметры. Иногда вам может потребоваться переопределить их (часто это делается в сложных средах, таких как Matlab или Cadence); если вы установите параметры среды, ~/.bashrcто оболочки, запускаемые из этих сред, потеряют настройки среды, и в результате все может работать неправильно. Это также применимо, если вы используете такой пакет, как modules , 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запускала корневая оболочка). Прежде чем пытаться использовать эти среды, проблем не было; начав их использовать, они были сбиты с толку неожиданной потерей их настроек.
честно говоря, в наши дни нет большой разницы, несмотря на то, что сказал гуру.
проблема в том, что в настоящее время мы авторизуемся графически, а не через оболочку входа. Раньше мы, пользователи unix, хотели видеть краткий отчет о том, что происходит на сервере сразу после входа в систему - затем мы запускаем X из командной строки - для создания этого отчета часто требуется некоторое время (например, 10-20 секунд). и тогда мы не хотим видеть то же самое, когда запускаем, например, xterm. таким образом разница.
в настоящее время я не думаю, что это различие имеет какое-то значение. Я думаю, что в наши дни, если вы исходите из bashrc в bash_profile, никто не сможет вас винить.
обратите внимание, что это не относится к macos x (каждое запущенное приложение terminal.app является оболочкой входа в систему)
Ну, насчет "Графических логинов", это зависит от того, какой * 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
Есть два случая
- / bin / sh связан с / bin / bash, но работает в режиме "POSIX / Bourne"
- / bin / sh - это / bin / dash (debian / ubuntu). Самый быстрый, но с меньшим количеством функций (поддержка ShellShock;) )
Таким образом, профиль / bin / sh - это ~ / .profile, а не ~ / .bash_profile, ~ / .zprofile
Этот файл следует использовать для настроек, «не зависящих от оболочки» , таких как путь и переменные среды.
НЕ ДОЛЖНА быть исполняемая программа для взаимодействия с пользователем только при входе в систему (проверка почты, удача и т. Д.)
~ /.* rc предназначены только для "интерактивных" сессий (например, псевдонимы ...)
Существует разница между bash и zsh для интерактивных оболочек входа.
Исходники bash только .bash_profile, а исходники zsh в порядке:
- ~ / .zprofile
- ~ / .zshrc
- ~ / 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" .
Таким образом, вы можете установить среду под рукой в ~ / .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 у вас есть две альтернативы:
- источник его в ~ / .bash_profile или ~ / .zprofile (или ~ / .zlogin), когда терминал действует как оболочка входа
- включить скрипт в ~ / .bashrc или ~ / zshrc
Это означает, что X-клиенты (например, emacs) должны запускаться из оболочки терминала, а не из графической оболочки!
"Я не могу получить никакого удовлетворения ..."