Variáveis de ambiente em bash_profile ou bashrc? ______ qstntxt ___

Eu encontrei esta pergunta [blog]: Diferença entre .bashrc e .bash_profile muito útil, mas depois de ver a resposta mais votada (muito bom por sinal), tenho mais perguntas. No final da resposta mais votada e correta, vejo a seguinte declaração:

%bl0ck_qu0te%
  1. Por que é uma má ideia (não estou tentando lutar, só quero entender)?

  2. Se eu quiser definir uma variável de ambiente e adicioná-la ao PATH (por exemplo, JAVA_HOME), onde seria o melhor lugar para colocar a entrada de exportação? em ~ / .bash_profile ou ~ / .bashrc ?

  3. Se a resposta à pergunta número 2 for ~ / .bash_profile , tenho mais duas perguntas:

    3.1. O que você colocaria em ~ / .bashrc ? apenas aliases?

    3.2. Em um shell que não seja de login, acredito que o ~ / .bash_profile não esteja sendo "escolhido".      Se a exportação da entrada JAVA_HOME estava em bash_profile, seria possível executar javac & Comandos java ? Os encontraria no PATH? É essa a razão pela qual alguns  postagens e fóruns sugerem a configuração de JAVA_HOME e similares para ~ / .bashrc ?

    Obrigado antecipadamente.

______ azszpr409192 ___

Em um sistema moderno, não é especialmente comum encontrar os casos em que isso é importante, mas acontece. (Em particular, se você usar operações shell em %code% , como %code% ou o formulário %code% em linha.)

%bl0ck_qu0te%

Você coloca coisas em %code% que não seriam herdadas automaticamente pelas sub-unidades; Isso significa aliases e funções, principalmente, embora às vezes você tenha configurações de variáveis que você não deseja visíveis fora do shell (isso é muito raro). Pode-se argumentar que esses devem ser exportados de alguma forma, mas várias tentativas experimentais se depararam com problemas de compatibilidade com a tentativa de escondê-las dentro do ambiente e foram praticamente abandonadas.

%bl0ck_qu0te%

Você coloca as configurações de ambiente em %code% para que recebam configurações iniciais sãs. Às vezes você vai querer anular estes (muitas vezes isso é feito por ambientes complexos, como Matlab ou Cadence); Se você colocar as configurações de ambiente em %code% , as camadas executadas nesses ambientes perderão as personalizações dos ambientes, e as coisas podem não funcionar adequadamente como resultado. Isso também se aplica se você usar um pacote como os módulos , virtualenv , rvm , etc. para gerenciar múltiplos ambientes de desenvolvimento; colocar suas configurações em %code% significa que você não pode executar o ambiente que deseja no seu editor, mas será forçado a entrar no padrão do sistema.

%bl0ck_qu0te%

Isso está correto; você normalmente quer que o shell inicial seja um shell de login e quaisquer shells iniciados sob esse não sejam shells de login. Se o shell inicial não for um shell de login, você não terá um %code% padrão ou várias outras configurações (incluindo seu exemplo %code% ).

A maioria dos ambientes de desktop iniciados a partir de gerenciadores de exibição (ou seja, a grande maioria dos logins gráficos) não configuram um ambiente de login para toda a área de trabalho, então você é forçado a executar o shell inicial em terminais como um shell de login . Isso causa vários problemas (notadamente que o %code% e os disponíveis para programas executados, por exemplo, painéis, não estão configurados corretamente, porque o painel não é um terminal e não executou %code% ), mas é um compromisso razoável dado que nem sempre é possível executar %code% no ambiente não interativo no início de uma sessão iniciada por um gerenciador de exibição, dependendo de seu conteúdo. Às vezes é sugerido colocar configurações de ambiente em %code% em vez de configurar um shell de login; como discutido acima, isso funciona desde que você não precise sobrescrever esse ambiente e causar quebras estranhas assim que fizer precisar fazer isso.

Recentemente, ajudei a diagnosticar um problema como esse no OS X, no qual um usuário que colocara as configurações em %code% depois começou a usar %code% e perlbrew viu um comportamento estranho, porque os ambientes configurados pelos dois foram "desfeitos" por %code% dentro dos editores e %code% (que no OS X, diferente do Linux, propaga o %code% do usuário para que %code% seja executado pelo shell de root). Antes de tentar usar esses ambientes, não havia problema; ao começar a usá-los, ficaram perplexos com a perda inesperada de suas configurações.

    
______ azszpr409190 ___

para ser honesto, há pouca diferença hoje em dia, apesar do que o guru tinha a dizer.

a questão por trás disso é que hoje em dia nós fazemos login graficamente, e não através de um shell de login. no passado, nós unix usuários gostam de ver um relatório curto do que está acontecendo em um servidor imediatamente após o login - então vamos iniciar o X por linha de comando - este relatório geralmente requer algum tempo para gerar (por exemplo, 10-20 segundos). e depois não queremos ver o mesmo quando começamos, e. xterm. assim a diferença.

hoje em dia eu não acho que a distinção seja importante agora. Eu acho que estes dias se você fonte bashrc em bash_profile ninguém poderia culpá-lo.

observe que isso não se aplica ao macos x (cada terminal.app iniciado é um shell de login)

    
______ azszpr1003123 ___

Bem, sobre "Logins Gráficos", depende de qual * DM você usa ...

Com o GDM (Gnome 3.18) eu tenho isto:

/ etc / gdm / Xsession

%pre%

Então, ~ / .profile é originado no login usando / bin / sh e não / bin / bash

Existem dois casos

  1. / bin / sh está vinculado a / bin / bash , mas é executado no modo "POSIX / Bourne"
  2. / bin / sh é / bin / traço (debian / ubuntu). Mais rápido, mas com menos recursos (suporte ao ShellShock;) )

Assim, o perfil / bin / sh é ~ / .profile e não ~ / .bash_profile, ~ / .zprofile

Este arquivo deve ser usado para configurações "agnóstico do shell" , como variáveis de caminho e ambiente.

NÃO programa executável para interação do usuário somente para login deve ser, mas aqui (cheque, fortuna, etc ...)

o ~ /.* rc é destinado apenas para sessões "interativas" (apelidos, por exemplo ...)

Existe uma diferença entre o bash e o zsh para shells interativos login

fontes bash somente .bash_profile, enquanto fontes zsh na ordem:

  1. ~ / .zprofile
  2. ~ / .zshrc
  3. ~ / zlogin (os aliases definidos em ~ / .zshrc estão disponíveis, no caso de shells "interativos" + "login"

A maneira certa de fazer ~ / .bash_profile foi respondida aqui:

Diferença entre .bashrc e .bash_profile

%pre%

Para ativar o teste (e a criação de perfil), você pode usar isso

~ / .bash_profile:

%pre%

~ / .zprofile:

%pre%

então, para testar:

%pre%

Então, o RVM / virtualenv deve ir em ~ / .profile, IMHO

Mas isso NÃO FUNCIONA , às vezes ...

Por exemplo, virualenvwrapper funciona somente se o shell rodando Xsession é um bash "original" (exportando BASH_VERSION)

Se você estiver em um sistema dash , a variável de ambiente e a configuração de caminho funcionarão, mas a definição da função virualenvwrapper não funcionará porque o script não é compatível com POSIX.

O script não apresenta nenhum erro, mas termina sem nenhuma definição "workon" .

Assim, você pode definir o ambiente disponível em ~ / .profile , apenas para ativar a execução correta do python a partir do cliente iniciado diretamente do X:

%pre%

link

link

Mas para virualenvwrapper você tem duas alternativas:

  1. coloque-o em ~ / .bash_profile ou ~ / .zprofile (ou ~ / .zlogin) quando o terminal atua como shell de login
  2. inclua o script em ~ / .bashrc ou ~ / zshrc

Isso significa que os clientes X (emacs, por exemplo) devem ser iniciados a partir do terminal e não do gráfico!

"Não tenho satisfação ..."

    
___

34

Eu encontrei esta pergunta [blog]: Diferença entre .bashrc e .bash_profile muito útil, mas depois de ver a resposta mais votada (muito bom por sinal), tenho mais perguntas. No final da resposta mais votada e correta, vejo a seguinte declaração:

Note that you may see here and there recommendations to either put environment variable definitions in ~/.bashrc or always launch login shells in terminals. Both are bad ideas.

  1. Por que é uma má ideia (não estou tentando lutar, só quero entender)?

  2. Se eu quiser definir uma variável de ambiente e adicioná-la ao PATH (por exemplo, JAVA_HOME), onde seria o melhor lugar para colocar a entrada de exportação? em ~ / .bash_profile ou ~ / .bashrc ?

  3. Se a resposta à pergunta número 2 for ~ / .bash_profile , tenho mais duas perguntas:

    3.1. O que você colocaria em ~ / .bashrc ? apenas aliases?

    3.2. Em um shell que não seja de login, acredito que o ~ / .bash_profile não esteja sendo "escolhido".      Se a exportação da entrada JAVA_HOME estava em bash_profile, seria possível executar javac & Comandos java ? Os encontraria no PATH? É essa a razão pela qual alguns  postagens e fóruns sugerem a configuração de JAVA_HOME e similares para ~ / .bashrc ?

    Obrigado antecipadamente.

por Viriato 06.04.2012 / 06:15

3 respostas

25

Em um sistema moderno, não é especialmente comum encontrar os casos em que isso é importante, mas acontece. (Em particular, se você usar operações shell em vim , como :r !command ou o formulário !<motion>command em linha.)

What would you put under ~/.bashrc? only aliases?

Você coloca coisas em ~/.bashrc que não seriam herdadas automaticamente pelas sub-unidades; Isso significa aliases e funções, principalmente, embora às vezes você tenha configurações de variáveis que você não deseja visíveis fora do shell (isso é muito raro). Pode-se argumentar que esses devem ser exportados de alguma forma, mas várias tentativas experimentais se depararam com problemas de compatibilidade com a tentativa de escondê-las dentro do ambiente e foram praticamente abandonadas.

If I want to set an environment variable and add it to the PATH (for example JAVA_HOME) where it would be the best place to put the export entry? in ~/.bash_profile or ~/.bashrc?

Você coloca as configurações de ambiente em ~/.bash_profile para que recebam configurações iniciais sãs. Às vezes você vai querer anular estes (muitas vezes isso é feito por ambientes complexos, como Matlab ou Cadence); Se você colocar as configurações de ambiente em ~/.bashrc , as camadas executadas nesses ambientes perderão as personalizações dos ambientes, e as coisas podem não funcionar adequadamente como resultado. Isso também se aplica se você usar um pacote como os módulos , virtualenv , rvm , etc. para gerenciar múltiplos ambientes de desenvolvimento; colocar suas configurações em ~/.bashrc significa que você não pode executar o ambiente que deseja no seu editor, mas será forçado a entrar no padrão do sistema.

In a non-login shell, I believe the ~/.bash_profile is not being "picked up".

Isso está correto; você normalmente quer que o shell inicial seja um shell de login e quaisquer shells iniciados sob esse não sejam shells de login. Se o shell inicial não for um shell de login, você não terá um PATH padrão ou várias outras configurações (incluindo seu exemplo JAVA_HOME ).

A maioria dos ambientes de desktop iniciados a partir de gerenciadores de exibição (ou seja, a grande maioria dos logins gráficos) não configuram um ambiente de login para toda a área de trabalho, então você é forçado a executar o shell inicial em terminais como um shell de login . Isso causa vários problemas (notadamente que o PATH e os disponíveis para programas executados, por exemplo, painéis, não estão configurados corretamente, porque o painel não é um terminal e não executou ~/.bash_profile ), mas é um compromisso razoável dado que nem sempre é possível executar ~/.bash_profile no ambiente não interativo no início de uma sessão iniciada por um gerenciador de exibição, dependendo de seu conteúdo. Às vezes é sugerido colocar configurações de ambiente em ~/.bashrc em vez de configurar um shell de login; como discutido acima, isso funciona desde que você não precise sobrescrever esse ambiente e causar quebras estranhas assim que fizer precisar fazer isso.

Recentemente, ajudei a diagnosticar um problema como esse no OS X, no qual um usuário que colocara as configurações em ~/.bashrc depois começou a usar rvm e perlbrew viu um comportamento estranho, porque os ambientes configurados pelos dois foram "desfeitos" por ~/.bashrc dentro dos editores e sudo (que no OS X, diferente do Linux, propaga o $HOME do usuário para que ~/.bashrc seja executado pelo shell de root). Antes de tentar usar esses ambientes, não havia problema; ao começar a usá-los, ficaram perplexos com a perda inesperada de suas configurações.

    
por 06.04.2012 / 06:36
2

para ser honesto, há pouca diferença hoje em dia, apesar do que o guru tinha a dizer.

a questão por trás disso é que hoje em dia nós fazemos login graficamente, e não através de um shell de login. no passado, nós unix usuários gostam de ver um relatório curto do que está acontecendo em um servidor imediatamente após o login - então vamos iniciar o X por linha de comando - este relatório geralmente requer algum tempo para gerar (por exemplo, 10-20 segundos). e depois não queremos ver o mesmo quando começamos, e. xterm. assim a diferença.

hoje em dia eu não acho que a distinção seja importante agora. Eu acho que estes dias se você fonte bashrc em bash_profile ninguém poderia culpá-lo.

observe que isso não se aplica ao macos x (cada terminal.app iniciado é um shell de login)

    
por 06.04.2012 / 06:28
1

Bem, sobre "Logins Gráficos", depende de qual * DM você usa ...

Com o GDM (Gnome 3.18) eu tenho isto:

/ 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"

Então, ~ / .profile é originado no login usando / bin / sh e não / bin / bash

Existem dois casos

  1. / bin / sh está vinculado a / bin / bash , mas é executado no modo "POSIX / Bourne"
  2. / bin / sh é / bin / traço (debian / ubuntu). Mais rápido, mas com menos recursos (suporte ao ShellShock;) )

Assim, o perfil / bin / sh é ~ / .profile e não ~ / .bash_profile, ~ / .zprofile

Este arquivo deve ser usado para configurações "agnóstico do shell" , como variáveis de caminho e ambiente.

NÃO programa executável para interação do usuário somente para login deve ser, mas aqui (cheque, fortuna, etc ...)

o ~ /.* rc é destinado apenas para sessões "interativas" (apelidos, por exemplo ...)

Existe uma diferença entre o bash e o zsh para shells interativos login

fontes bash somente .bash_profile, enquanto fontes zsh na ordem:

  1. ~ / .zprofile
  2. ~ / .zshrc
  3. ~ / zlogin (os aliases definidos em ~ / .zshrc estão disponíveis, no caso de shells "interativos" + "login"

A maneira certa de fazer ~ / .bash_profile foi respondida aqui:

Diferença entre .bashrc e .bash_profile

if [ -r ~/.profile ]; then . ~/.profile; fi
case "$-" in *i*) if [ -r ~/.bashrc ]; then . ~/.bashrc; fi;; esac

Para ativar o teste (e a criação de perfil), você pode usar isso

~ / .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'
# ------------------------------------------------

então, para testar:

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

Então, o RVM / virtualenv deve ir em ~ / .profile, IMHO

Mas isso NÃO FUNCIONA , às vezes ...

Por exemplo, virualenvwrapper funciona somente se o shell rodando Xsession é um bash "original" (exportando BASH_VERSION)

Se você estiver em um sistema dash , a variável de ambiente e a configuração de caminho funcionarão, mas a definição da função virualenvwrapper não funcionará porque o script não é compatível com POSIX.

O script não apresenta nenhum erro, mas termina sem nenhuma definição "workon" .

Assim, você pode definir o ambiente disponível em ~ / .profile , apenas para ativar a execução correta do python a partir do cliente iniciado diretamente do X:

export VIRTUAL_ENV="/home/mike/var/virtualenvs/myvirtualenv"
export PATH="$VIRTUAL_ENV/bin:$PATH"
unset PYTHON_HOME

link

link

Mas para virualenvwrapper você tem duas alternativas:

  1. coloque-o em ~ / .bash_profile ou ~ / .zprofile (ou ~ / .zlogin) quando o terminal atua como shell de login
  2. inclua o script em ~ / .bashrc ou ~ / zshrc

Isso significa que os clientes X (emacs, por exemplo) devem ser iniciados a partir do terminal e não do gráfico!

"Não tenho satisfação ..."

    
por 20.11.2015 / 11:14