Variáveis de ambiente pessoal da convenção

Question

Existe uma convenção Unix para definir variáveis de ambiente pessoal? Eu li que eles devem ser colocados em $HOME/.bash_profile em vez de $HOME/.bashrc . No entanto, eu estava pensando em fornecer uma maneira de distinguir minhas próprias variáveis. Desta forma, embora eu esquecesse uma, eu poderia dizer, à primeira vista, se ela foi definida por mim ou não. Por exemplo, quando eu faço o autocompletar no terminal eu pude fazer minhas variáveis começarem com um sublinhado, ou um menos 'm' como em uma das convenções da linguagem C++ . Eu entendo que pode não haver uma resposta absoluta, mas gostaria de ouvir sobre algumas boas práticas e convenções que trabalham com esse propósito: fornecer uma maneira simples de distinguir as variáveis de ambiente do sistema das pessoais.

    

Answer 1

Onde definir variáveis de ambiente é coberto em Qual é a melhor maneira de distribuir as variáveis de ambiente?

Em relação à nomenclatura, o principal motivo para definir variáveis de ambiente é porque um aplicativo as utiliza, portanto, você não pode escolher o nome.

Não há conceito de namespaces para variáveis de ambiente. O mais próximo é escolher um prefixo, geralmente no formato SOMETHING_ (ou seja, o prefixo termina com um sublinhado e você tem as variáveis SOMETHING_FOO , SOMETHING_BAR ,…). Mas a maioria das variáveis não é para um aplicativo específico, mas sim uma família de aplicativos. Se uma variável é apenas significativa em um aplicativo, geralmente deve ser uma opção de linha de comando. Portanto, não há muita necessidade de namespaces.

Se você está definindo variáveis apenas para uso na linha de comando, então não use variáveis de ambiente, use variáveis shell . (Consulte Diferença entre variáveis de ambiente e variáveis de ambiente exportadas no bash ) Se você definir uma variável em um script de shell e não usar export , será uma variável do shell, não uma variável de ambiente, e ficará visível apenas no shell em que você os definiu. Então, se você está definindo uma variável para usar na linha de comando:

• Defina-o no arquivo de inicialização interativo do shell ( ~/.bashrc para bash, ~/.zshrc para zsh, ~/.config/fish/config.fish para fish).
• Não export it.
• Há uma convenção generalizada de que as variáveis de ambiente são todas maiúsculas e as variáveis de shell são todas minúsculas.

Para seu próprio uso, escolha os nomes que quiser, contanto que eles não entrem em conflito com as variáveis de ambiente que você usa (as variáveis de ambiente são importadas automaticamente como variáveis de shell). Eu não recomendo um sublinhado inicial porque é isso que os sistemas de completamento do bash e do zsh usam internamente.

    

Answer 2

Aqui estão minhas recomendações sobre onde definir o ambiente, junto com as explicações.

Os detalhes relevantes são:

• O arquivo de perfil do usuário é ~/.bash_profile , ~/.bash_login ou ~/.profile . Eu sugiro usar um dos dois primeiros, porque o último se sobrepõe a outros shells. No entanto, consulte a nota sobre o login da GUI no final.

• O usuário arquivo rc é ~/.bashrc .

• Um shell de login interativo (por exemplo, um login do console ou ssh login) lê apenas o arquivo de perfil.

• Um shell de login não interativo é raro, mas pode ocorrer durante o login da GUI. De qualquer forma, se for um shell Bash, ele age como um shell de login não interativo e lê apenas o arquivo de perfil.

• Um shell nãologin interativo (por exemplo, uma nova guia no XTerm / Konsole) lê o arquivo rc.

• Um shell nonlogin não interativo (por exemplo, shell script) não lê nenhum, com uma exceção importante: Se iniciado por ssh , ele lê o arquivo rc.

A exceção envolvendo ssh é motivada pelo fato de que quando um script é executado por ssh ( ssh $host my_remote_script ), o ambiente (principalmente PATH ) ainda não está configurado, como é o caso ao executar um local roteiro. Assim, IMO, a exceção é uma motivação para definir o ambiente em ~/.bashrc , para que o mesmo ambiente seja usado para scripts chamados localmente e remotamente invocados.

Com base em tudo isso, minhas recomendações são:

• Arquivo de perfil:

  • Não defina nada que possa ser útil para um script invocado remotamente, incluindo PATH .
  • Origem incondicional do arquivo rc: . ~/.bashrc .

• Arquivo Rc:

  • Defina as variáveis de ambiente conforme necessário.

  • Tenha em atenção que o ficheiro será originado quando o ambiente já estiver definido (por invólucros interativos sem registo). Então, se você fizer incondicionalmente PATH=$HOME/bin:$PATH , você pode acabar com PATH=$HOME/bin:$HOME/bin:... depois de fazer o sourcing duas vezes (um aborrecimento, não um erro). Uma solução fácil é proteger a configuração do ambiente:

    # ~/.bashrc
    if [ ! "${MY_ENV_SET:-}" ]; then
        PATH=...
        ...
        export MY_ENV_SET=1
    fi
    

  • Defina apenas detalhes de shell para shells interativos:

    ...
    [ "$PS1" ] || return 0
    PS1=<fancy_colored_prompt>
    source ~/.bash_alias
    eval $(dircolors -b ~/.dircolors)
    source /etc/bash_completion
    

Login da GUI . Uma última coisa importante que você precisa considerar é como sua GUI define PATH durante a inicialização. Isso pode ser feito usando o Bash, ou não. No meu caso, eu uso o KDE, e esse arquivo é originado durante a inicialização:

# ~/.kde/env/path.sh
# https://userbase.kde.org/Session_Environment_Variables
PATH=$(env -i /bin/bash -lc 'echo $PATH')

Isso invoca um shell Bash de login (não raro), usando um ambiente vazio, que também origina o arquivo rc, e tudo é consistente.

Se você estiver usando outra GUI (Gnome?), você deve verificar como PATH é definido durante a inicialização. Se sua GUI origina ~/.profile , certifique-se de também fornecer o arquivo rc de lá.