☰

Escolhendo entre .bashrc, .profile, .bash_profile, etc

tag-icon • tag-icon unix environment-variables
Escolhendo entre .bashrc, .profile, .bash_profile, etc

Isso é constrangedor, mas depois de muitos anos usando sistemas POSIX em tempo integral, ainda tenho dificuldade em descobrir se uma personalização de shell deve ser feita em .bashrc, .profileou em outro lugar. Sem mencionar alguns dos arquivos de configuração específicos do sistema operacional, como .pam_environment.

Sim, sei como analisar a documentação e saber quando cada arquivo está ou não carregado. O que estou querendo saber é se alguém elaborou diretrizes abrangentes sobre como decidir em qual arquivo colocar um determinado tipo de personalização.

Responder1

DR:

  • ~/.bash_profiledeve ser super simples e apenas carregar .profilee .bashrc(nessa ordem)

  • ~/.profiletem coisas NÃO especificamente relacionadas ao bash, como variáveis ​​de ambiente ( PATHe amigos)

  • ~/.bashrctem tudo o que você deseja em uma linha de comando interativa. Prompt de comando, EDITORvariável, aliases bash para meu uso

Algumas outras notas:

  • Qualquer coisa que deva estar disponível para aplicativos gráficos OU para sh (ou bash invocado como sh) DEVE estar em~/.profile

  • ~/.bashrcnão deve produzir nada

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

  • Certifique-se de que isso ~/.bash_loginnão existe.

Responder2

Nos últimos anos, tive muito tempo a perder, entãoterpesquisei isso por um pouco mais do que apenas 10 minutos. Não tenho ideia se este é o melhor layout, é apenas aquele que funciona corretamente em praticamente todos os casos.

Os requisitos:

  • ~/.profiledeve ser compatível com qualquer /bin/sh – isso inclui bash, dash, ksh, qualquer outra coisa que uma distro possa escolher usar.

  • Variáveis ​​de ambiente devem ser colocadas em um arquivo que seja lido tanto por logins de console (ou seja, um shell de 'login') quanto por logins gráficos (ou seja, gerenciadores de exibição como GDM, LightDM ou LXDM).

  • Não faz muito sentido terambos ~/.profilee ~/.bash_profile. Se o último estiver faltando, o bash usará o primeiro com prazer, e quaisquer linhas específicas do bash podem ser protegidas com uma verificação para $BASHou $BASH_VERSION.

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

Omais simplesconfiguração seria:

  • Tenha um ~/.profileque defina todas as variáveis ​​de ambiente (exceto as específicas do bash), talvez imprima uma ou duas linhas e, em seguida, as fontes ~/.bashrcse estiverem sendo executadas pelo bash, aderindo à sintaxe compatível com sh, caso contrário.

    exportar TZ="Europa/Paris"
exportar EDITOR = "vim"
se ["$BASH"]; então
    . ~/.bashrc
fi
tempo de atividade

  • Tenha um ~/.bashrcque execute qualquer configuração específica do shell, protegido com uma verificação demodo interativopara evitar quebrar coisas como sftpno Debian (onde o bash é compilado com a opção de carregar ~/.bashrcmesmo para shells não interativos):

    [[ $- == *i* ]] || retornar 0

PS1='\h \w \$ '

start() { sudo serviço "$1" start; }

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

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

    se ! ["$PREFIXO"]; 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=./.ambiente        # não é um erro de digitação; precisa ser um caminho, mas ~ não funcionará

    Então, é claro, atualizando ~/.environpara unset BASH_ENV.

Conclusão? As 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 umaimensodor na bunda.

Responder3

Veja issoexcelente postagem no blog de ShreevatsaR. Aqui está um trecho, mas vá para a postagem do blog, que inclui uma explicação para termos como "shell de login", um fluxograma e uma tabela semelhante para Zsh.

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

Login interativo Não login interativo Roteiro
/etc/profile A
/etc/bash.bashrc A
~/.bashrc B
~/.bash_profile B1
~/.bash_login B2
~/.profile B3
BASH_ENV A
~/.bash_logout C

Responder4

Desisti de tentar descobrir isso e criei um script ( ~/.shell-setup) que extraí de todos os outros.

Essa abordagem requer ~/.shell-setupdois recursos:

  1. Execute apenas uma vez, mesmo quando obtido repetidamente (useIncluir guardas)
  2. Não gere nenhuma saída indesejada (detecte quando a saída está ok)

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

O número 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 não me lembro como descobri isso ou por quedetectando um shell interativonão foi suficiente.

informação relacionada