Змінні середовища в bash_profile чи bashrc?


36

Я знайшов це питання [блог]: Різниця між .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 ?

    Заздалегідь спасибі.

Відповіді:


26

У сучасній системі не особливо часто зустрічатися з випадками, коли це має значення, але це трапляється. (Зокрема, якщо ви використовуєте операції з оболонкою у 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він управлявся кореневою оболонкою). Перш ніж спробувати використовувати ці середовища, не було проблем; почавши їх використовувати, їх здивувала несподівана втрата налаштувань.


1
Я думаю, що я розумію, мені, можливо, доведеться прочитати його більше разів, щоб більше інтерналізувати, але я роблю висновок про наступне. У корпоративному середовищі, щоб мати кращий контроль над індивідуальними оболонками без побічних ефектів глобального, найкраще застосовувати змінні середовища у ~ / .bash_profile . В особистому середовищі, наприклад Ubuntu або Linux Mint, щоб PATH був правильно встановлений, я повинен встановити його під ~ / .bashrc (або навіть у / etc / profile ). Я прав?
Віріато

Це пов'язано менше з корпоративним середовищем, ніж з тим, чи ви просто користувач чи розробник; такі системи, як modulesі rvmє інструментами для розробників, як і Matlab і Cadence для дещо різних визначень "розробник". Просте розвиток також не вимагає від них, але коли вам потрібно тест з декількома версіями Ruby, Perl або Python , то ви дійсно хочете що - щось подібне rvm, perlbrewі virtualenv(відповідно) навколо , щоб допомогти зберегти все це прямо.
geekosaur

2

якщо чесно, різниці в ці дні мало, незважаючи на те, що мав сказати гуру.

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

в даний час я не думаю, що відмінність зараз важлива. Я думаю, що в ці дні, якщо ви джерелом bashrc в bash_profile, ніхто не може вас звинуватити.

зауважте, що це не стосується macos x (кожен запущений термінал.app - це оболонка для входу)


Я не зовсім впевнений, що цілком розумію, але на роботі, коли я входжу через ssh, який є оболонкою для входу, тоді bash_profile і bashrc отримують джерело, тому я думаю, що в цьому випадку це не має значення. Але якщо я входжу графічно (що це означає)? як увійти до мого особистого ubuntu?
Віріато

Погодьтеся з відповіддю @bubu тут - будь-яка установка, де ~/.bash_profileнемає джерела, ~/.bashrcє досить складною роботою і налаштуванням на зламані. Програми графічних терміналів означають, що простіше просто джерело ~ / .bashrc і помістити всі конфігурації туди.
RichVel

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 / 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, IMHO

Але це НЕ ПРАЦЮЄ , іноді ...

Наприклад, virualenvwrapper працює лише в тому випадку, якщо оболонка, що працює з Xsession, є "оригінальним" башем (експорт BASH_VERSION)

Якщо ви перебуваєте в системі тире , змінна середовища та налаштування шляху працюють, але визначення функції virualenvwrapper не працює, оскільки сценарій не сумісний з POSIX.

Сценарій не дає жодних помилок, але він закінчується без будь-якого визначення "робочого" .

Таким чином, ви можете встановити навколишнє середовище в ~ / .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/isissue/9061991-setting-up-your-computer-virtualenvwrapper-linux-all

Але для virualenvwrapper у вас є дві альтернативи:

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

Це означає, що клієнтів X (наприклад, emacs) слід запускати з термінальної оболонки, а не з графічної!

"Я не можу отримати задоволення ..."


Повна інша історія запуску сервісів з Systemd деяких можливих альтернатив: писати обгортку сценарій, визначити середу в «сервіс» файл визначення, скидаючи середу в «окр» файл , щоб бути отримані в батьківській оболонці. Речі стають складнішими за RVM / virtualenv ...
hute37
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.