Questão Escolhendo entre .bashrc, .profile, .bash_profile, etc [duplicado]


Esta questão já tem uma resposta aqui:

Isso é embaraçoso, mas depois de muitos anos usando sistemas POSIX em tempo integral, eu ainda tenho dificuldade em descobrir se uma customização de shell deve entrar. .bashrc, .profile, Ou em outro lugar. Para não mencionar alguns dos arquivos de configuração específicos do sistema operacional como .pam_environment.

Sim, sei como criar quebra-cabeças na documentação e saber quando cada arquivo é ou não carregado. O que eu estou querendo saber é se alguém tem todas as orientações completas sobre como decidir em qual arquivo colocar um determinado tipo de personalização.


169


origem


esta questão não deve ser marcada como duplicada, a razão é que .profile não está disponível na questão adicionada. - Premraj
Resposta: serverfault.com/q/261802/270464 - Premraj


Respostas:


TL; DR:

  • ~/.bash_profile deve ser super simples e carregar apenas .profile e .bashrc (naquela ordem)

  • ~/.profile tem o material não especificamente relacionados a bash, como variáveis ​​de ambiente (PATH e amigos)

  • ~/.bashrc Tem tudo o que você deseja em uma linha de comando interativa. Prompt de comando, EDITOR aliases bash, variáveis ​​para meu uso

Algumas outras notas:

  • Qualquer coisa que deve estar disponível para aplicações gráficas OU sh (ou bash invocado como sh) DEVE estar em ~/.profile

  • ~/.bashrc não deve produzir nada

  • Qualquer coisa que deveria estar disponível apenas para os shells de login deve entrar ~/.profile

  • Garanta que ~/.bash_login não existe.


190



+1, isso permite ~/.profile configurar corretamente o ambiente para serviços como GDM / LightDM / LXDM que explicitamente executam / bin / sh. - grawity
Minhas .bashrc Produz bastante coisa, você pode comentar sobre isso? Em particular, onde devo colocar o resultado da saudação? - Calimo
@Calimo: Produz apenas material de saída no modo interativo. Você pode testar usando [[ $- == *i* ]], isto é, procurando 'i' no especial $- variável. Claro, isso só importa em primeiro lugar em sistemas onde o bash é compilado para ler .bashrc no modo não interativo. (Isto é, Debian mas não Arch.) Mas é uma causa frequente de mensagens de erro misteriosas ao tentar se conectar usando sftp ou scp ou ferramentas semelhantes. - grawity
Agora eu tenho que saber - por que o .bash_login não deveria existir? O que isso faz? - tedder42
@ tedder42: Faz o mesmo que .bash_profile e .profile. Mas o bash apenas lê o primeiro de três. Significado, se você tem um .bash_loginentão ambos .profile e .bash_profile será misteriosamente ignorado. - grawity


Nos últimos anos, tive muito tempo a perder, então eu ter Pesquisei isso por mais de 10 minutos. Eu não tenho idéia se este é o melhor layout, é apenas um que acontece para funcionar corretamente em praticamente todos os casos.

Os requisitos:

  • ~/.profile deve ser compatível com qualquer / bin / sh - isso inclui bash, dash, ksh, o que mais uma distro escolher usar.

  • As variáveis ​​de ambiente devem ser colocadas em um arquivo que seja lido pelos dois logons do console (por exemplo, um shell 'login') e logins gráficos (por exemplo, gerenciadores de exibição como GDM, LightDM ou LXDM).

  • Há muito pouco sentido em ter ambos  ~/.profile e ~/.bash_profile. Se este último estiver faltando, o bash irá alegremente usar o primeiro, e qualquer linha específica do bash pode ser guardada com um cheque $BASH ou $BASH_VERSION.

  • A separação entre *profile e *rc é que o primeiro é usado para shells de "login" e o último sempre que você abre uma janela de terminal. No entanto, bash no modo 'login' não fornece ~/.bashrc, assim sendo ~/.profile precisa fazer isso manualmente.

o mais simples configuração seria:

  • Tenha um ~/.profile que define todas as variáveis ​​de ambiente (exceto as específicas de bash), talvez imprima uma ou duas linhas e, em seguida, fontes ~/.bashrc se estiver sendo executado pelo bash, mantendo a sintaxe compatível com sh, caso contrário.

    exportação TZ = "Europa / Paris"
    exportar EDITOR = "vim"
    if ["$ BASH"]; então
        . ~ / .bashrc
    fi
    tempo de atividade
    
  • Tenha um ~/.bashrc que executa qualquer configuração específica do shell, protegida com uma verificação de modo interativo para evitar quebrar coisas como sftp no Debian (onde o bash é compilado com a opção de carregar ~/.bashrcmesmo para shells não interativos):

    [[$ - == * i *]] || return 0
    
    PS1 = '\ h \ w \ $'
    
    start () {serviço sudo "$ 1" start; }
    

No entanto, existe também o problema de certos comandos não interativos (por exemplo, ssh <host> lspular ~/.profile, mas variáveis ​​de ambiente seriam muito úteis para eles.

  • Certas distribuições (por exemplo, Debian) compilam o bash com a opção de fonte ~/.bashrc para esses logins não interativos. Neste caso, achei útil mover todas as variáveis ​​de ambiente (o export ... linhas) para um arquivo separado, ~/.environe para obtê-lo de ambos  .profile e .bashrc, com um guarda para evitar fazer duas vezes:

    E se ! ["$ PREFIX"]; então # ou $ EDITOR ou $ TZ ou ...
        . ~ / .environ # geralmente qualquer variável que o próprio .environ definiria
    fi
    
  • Infelizmente, para outras distribuições (por exemplo, Arch), não encontrei uma solução muito boa. Uma possibilidade é usar o módulo PAM pam_env (habilitado por padrão), colocando o seguinte em ~/.pam_environment:

    BASH_ENV =. /. Environ # não é um erro de digitação; precisa ser um caminho, mas não funciona
    

    Então, claro, atualizando ~/.environ para unset BASH_ENV.


Conclusão? Conchas são uma dor. Variáveis ​​de ambiente são uma dor. Opções de tempo de compilação específicas da distribuição são imenso dor no rabo.


45



+1 para o último parágrafo, mas prefiro pesquisar .profile e .bashrc a partir de .bash_profile e mantendo .profile limpar \ limpo. - nyuszika7h
@ nyuszika7h: meu .profile  está limpo, obrigado. - grawity
Observe o comentário re toda vez que você abrir uma janela é o contrário para OSX - Mark
"Há muito pouco sentido em ter ambos ~/.profile e ~/.bash_profile": Eu discordo. Veja a resposta de Dan para o porquê. - rubenvb
@rubenvb Você pode citar a parte relevante? Eu acho que é bom ter apenas um .profile e guarda o bash-específicas com condicionais. - Kelvin


Veja isso excelente postagem no blog por ShreevatsaR. Aqui está um extrato, mas vá para o post do blog, ele inclui uma explicação para termos como "shell de login", um fluxograma e uma tabela semelhante para o Zsh.

Para Bash, eles funcionam da seguinte maneira. Leia a coluna apropriada. Executa A, depois B, depois C, etc. O B1, B2, B3 significa que executa apenas o primeiro desses arquivos encontrados.

+----------------+-----------+-----------+------+
|                |Interactive|Interactive|Script|
|                |login      |non-login  |      |
+----------------+-----------+-----------+------+
|/etc/profile    |   A       |           |      |
+----------------+-----------+-----------+------+
|/etc/bash.bashrc|           |    A      |      |
+----------------+-----------+-----------+------+
|~/.bashrc       |           |    B      |      |
+----------------+-----------+-----------+------+
|~/.bash_profile |   B1      |           |      |
+----------------+-----------+-----------+------+
|~/.bash_login   |   B2      |           |      |
+----------------+-----------+-----------+------+
|~/.profile      |   B3      |           |      |
+----------------+-----------+-----------+------+
|BASH_ENV        |           |           |  A   |
+----------------+-----------+-----------+------+
|                |           |           |      |
+----------------+-----------+-----------+------+
|                |           |           |      |
+----------------+-----------+-----------+------+
|~/.bash_logout  |    C      |           |      |
+----------------+-----------+-----------+------+

29



Isso é legal. É importante notar que geralmente /etc/profile chamadas /etc/bash.bashrce ~/.profile chamadas ~.bashrc. Então, efetivamente /etc/bash.bashrc e ~/.bashrc estão sendo executados para logins interativos também. - wisbucky
Note que algumas distribuições parecem anular este esquema (com conseqüências estranhas) - ver, por exemplo, meu bugreport para opensuse aqui: bugzilla.opensuse.org/show_bug.cgi?id=1078124 - Christian Herenz


Eu ofereço minhas diretrizes "abrangentes":

  • Faço .bash_profile e .profile carga .bashrc se existir, usando, e. [ -r $HOME/.bashrc ] && source $HOME/.bashrc
  • Coloque tudo mais em .bashrc.
  • Pare de se preocupar.
  • A cada quatro anos, passe dez minutos pesquisando essa questão antes de desistir e voltar a "não se preocupar".

EDIT: Adicionado citações assustadoras para "abrangente" apenas no caso de alguém é tentado a acreditar. ;)


19



Tendo ambos .bash_profile e .profile é um pouco redundante; você só precisa do último. Você precisa torná-lo / bin / sh-proof, embora: if [ "$BASH" ] && [ -r ~/.bashrc ]; then . ~/.bashrc; fi, como existem programas (a saber, o gdm / lightdm) que manualmente fonte o arquivo de um script / bin / sh. Isso também significa que o ambiente mantido em .bashrc seria ineficaz. Tive que -1, uma vez que suas diretrizes "abrangentes" não funcionarão em muitos sistemas, como eu havia descoberto da maneira mais difícil várias vezes. - grawity
Sem problema, eu ficaria feliz em pagar uma -1 por uma resposta que não seja meramente "abrangente", e você certamente ganhou esse título. - Mechanical Fish


Eu desisti de tentar descobrir isso e fiz um script (~/.shell-setup) que eu compro de todos os outros.

Esta abordagem requer ~/.shell-setup ter dois recursos:

  1. Execute somente uma vez, mesmo quando originado repetidamente (use Inclua guardas)
  2. Não gere nenhuma saída indesejada (detecte quando a saída está ok)

# 1 é bastante normal, embora talvez não seja muito usado em scripts de shell.

# 2 é mais complicado. Aqui está o que eu uso no bash:

if [ "" == "$BASH_EXECUTION_STRING" -a "" == "$DESKTOP_SESSION" ]; then
    echo "Hello user!" # ... etc
fi

Infelizmente eu não me lembro como cheguei a isso, ou porque detectando um shell interativo não foi suficiente.


0





Coloque tudo em .bashrc e depois fonte .bashrc a partir de .profile

Na página man bash (no OS X 10.9):

Quando um shell interativo que não é um shell de login é iniciado, o bash lê e executa comandos de ~ / .bashrc, se esse arquivo existir. Isso pode ser inibido usando a opção --norc. A opção de arquivo --rcfile forçará o bash a ler e executar comandos do arquivo em vez de ~ / .bashrc

O texto acima é porque tudo é colocado em .bashrc. No entanto, há um comportamento um pouco diferente quando você está lidando com um shell de login. Novamente, citando a página man:

Quando o bash é invocado como um shell de login interativo, ou como um shell não interativo com a opção --login, ele primeiro lê e executa comandos do arquivo / etc / profile, se esse arquivo existir. Depois de ler esse arquivo, ele procura por ~ / .bash_profile, ~ / .bash_login e ~ / .profile, nessa ordem, e lê e executa os comandos do primeiro que existe e é legível. A opção --noprofile pode ser usada quando o shell é iniciado para inibir esse comportamento.

.profile é lido para shells de login, mas .bashrc não é. Duplicando tudo isso em .bashrc é ruim, então precisamos fonte em .profile para que o comportamento permaneça consistente.

No entanto, você não quer fonte .bashrc a partir de .profile incondicionalmente. Por favor, veja os comentários e outras respostas para detalhes adicionais.


-1



-1 NÃO fonte .bashrc a partir de .profile. Veja a resposta de @ DanRabinowitz. - nyuszika7h
Pelo menos não incondicionalmente. - nyuszika7h
[ -n "$BASH" -a -f ~/.bashrc ] && . ~/.bashrc seria um doce oneliner para .profile. - John WH Smith
@ nyuszika7h, por que não? Todo mundo parece para sugerir isso. - Pacerier