Переменные среды в bash_profile или bashrc?

Я нашел этот вопрос [блог]: Разница между .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 ?

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

В современной системе не так часто встречаются случаи, когда это важно, но это случается. (В частности, если вы используете операции оболочки в 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запускала корневая оболочка). Прежде чем пытаться использовать эти среды, проблем не было; начав использовать их, они были сбиты с толку неожиданной потерей своих настроек.

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

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

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

обратите внимание, что это не относится к macos x (каждый запущенный терминал.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

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

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) должны запускаться из оболочки терминала, а не из графической оболочки!

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