TL; DR: Coloque seus comandos export em .profile em vez disso, remova ou renomeie .bash_profile e saia e volte para aplicar suas alterações .
Como os arquivos "perfil" por usuário são usados
A maioria dos ambientes de área de trabalho é configurada, por padrão, para que o arquivo .profile em seu diretório inicial seja originado quando você faz login graficamente. Parece que você está usando o ambiente de desktop padrão do Ubuntu, que é o GNOME com Unity. Isso deve funcionar.
A maioria dos shells ao estilo Bourne também fornecerão .profile , quando invocados como shell de login . Isso inclui o bash, exceto que .profile é originado somente se .bash_profile e .bash_login não existirem. Se .bash_profile existir, será usado; caso contrário, se .bash_login existir, ele será usado; e de outra forma, .profile é usado.
A razão para isso é que os comandos que não dependem do shell sendo bash, que você deseja executar no login, podem ir em .profile e, se houver comandos específicos do bash, você pode colocá-los em um desses outros dois arquivos. Normalmente, você usaria .profile de dentro de .bash_profile ou .bash_login .
Se os únicos comandos em .bash_profile forem os que você mostrou em sua pergunta, então você não precisa usar .bash_profile , porque esses comandos são portáveis em shells estilo Bourne. Você pode então remover .bash_profile (ou renomeá-lo para algo como .bash_profile.old ) e colocar esses comandos em .profile . Eles podem ir na parte inferior desse arquivo, e você pode fazer o backup primeiro, se quiser (nomes razoáveis para o backup podem ser .profile.old ou .profile.orig , mas você pode nomear o backup como quiser, porque na verdade não é se acostumar).
A ausência de .bash_profile - desde .bash_login também não existe - fará com que .profile seja usado. ( .profile provavelmente já está sendo usado para o seu login gráfico.)
O que fazer
Remover ou renomear .bash_profile .
Edite .profile . Geralmente é assim:
# ~/.profile: executed by the command interpreter for login shells.
# This file is not read by bash(1), if ~/.bash_profile or ~/.bash_login
# exists.
# see /usr/share/doc/bash/examples/startup-files for examples.
# the files are located in the bash-doc package.
# the default umask is set in /etc/profile; for setting the umask
# for ssh logins, install and configure the libpam-umask package.
#umask 022
# if running bash
if [ -n "$BASH_VERSION" ]; then
# include .bashrc if it exists
if [ -f "$HOME/.bashrc" ]; then
. "$HOME/.bashrc"
fi
fi
# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
PATH="$HOME/bin:$PATH"
fi
Você pode simplesmente adicionar todas as onze linhas de código (seis, se não contar linhas em branco e comentários) na parte inferior de .profile , salvar o arquivo, sair e voltar.
Opcional: você pode considerar reescrever essas atribuições
Embora isso seja totalmente opcional, convém aproveitar esta oportunidade para refatorar suas instruções export . Atualmente você usa:
### export JAVA_HOME variable
export JAVA_HOME=/usr/local/dev/jdk1.8.0_20
export PATH=$PATH:$JAVA_HOME/bin
### export M2_HOME
export M2_HOME=/usr/local/dev/maven
export PATH=$PATH:$M2_HOME/bin
### export SCALA_HOME
export SCALA_HOME=/usr/local/dev/scala-2.11.2
export PATH=$PATH:$SCALA_HOME/bin
PATH é modificado três vezes, uma vez para cada outra variável sendo atribuída. Tudo bem e pode ser o que você quer. Mas é mais longo e (na minha opinião) menos auto-documentado que esta alternativa:
# export Java, Maven, and Scala homes and add their bins to PATH
export JAVA_HOME=/usr/local/dev/jdk1.8.0_20
export M2_HOME=/usr/local/dev/maven
export SCALA_HOME=/usr/local/dev/scala-2.11.2
export PATH=$PATH:$JAVA_HOME/bin:$M2_HOME/bin:$SCALA_HOME/bin
Se você precisar de .bash_profile para algo mais (mas você provavelmente não precisa)
Devo observar que o que eu recomendei é muito semelhante a algo que c0rp disse anteriormente (em um comentário em uma postagem que foi excluída desde então):
Coloque todas as variáveis em
~/.profilee fonte~/.profileem~/.bash_profile.~/.profileé executado automaticamente pelo DisplayManager durante a sessão da área de trabalho do processo de inicialização, bem como pelo login shell quando alguém efetua login a partir do console textual .
Mas minha recomendação difere em um aspecto significativo: já que me parece que você não precisa de um arquivo .bash_profile , eu recomendo que você o mova para fora do caminho (isto é, exclua ou renomeie), e não se preocupe em fazer o sourcing em .profile .
Se você por algum motivo precisar de um .bash_profile file , então você deve evitar ter definições de variáveis de ambiente (como elas se aplicam apenas a logons bash , e não o seu login gráfico).
Se você tiver comandos específicos do bash que devem estar em um arquivo .bash_profile , como c0rp disse, você pode colocar essa linha no arquivo .bash_profile :
. $HOME/.profile
Em seguida, .bash_profile fornecerá .profile e os comandos em .profile serão executados para os logins bash e non-bash.
Se usar .profile não funciona
Em seguida, será necessária mais resolução de problemas, mas vale a pena notar que:
- Alguns gerenciadores de exibição source
.profilepor padrão; alguns aparentemente não. - Isso também pode depender do ambiente de área de trabalho (ou seja, nos perfis de sessão por DE que contam a DM como iniciar a sessão gráfica).
Eu ouvi pessoas dizerem que o LightDM não fonte .profile e Eu acho que isso é verdade, pelo menos, como é empacotado em alguns SO . Eu não posso falar sobre o assunto absolutamente, mas nos sistemas Ubuntu que eu usei com o LightDM como gerenciador de exibição, .profile foi originado em sessões gráficas e as exportações variáveis em .profile foram eficazes.
(Nem sempre funcionou para mim em outros sistemas operacionais, como o Debian.)
Se o uso de .profile não funcionar: um Quick & amp; Alternativa Suja
Se você estiver disposto a ter alguma redundância nas suas definições de variáveis, poderá usar .pam_environment como uma alternativa rápida.
man pam_env explica que é possível definir variáveis de ambiente como KEY=VAL pares em envfiles. Como essa página de manual explica, o envfile de todo o sistema padrão é /etc/environment e os envfiles padrão por usuário são ~/.pam_environment .
Então, você poderia criar um arquivo .pam_environment em seu diretório pessoal e colocar algo assim:
JAVA_HOME="/usr/local/dev/jdk1.8.0_20"
M2_HOME="/usr/local/dev/maven"
SCALA_HOME="/usr/local/dev/scala-2.11.2"
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/local/dev/jdk1.8.0_20/bin:/usr/local/dev/maven/bin:/usr/local/dev/scala-2.11.2/bin"
Como você pode ver, alterar qualquer coisa exigiria que você fizesse várias alterações, e esse alto nível de duplicação dificulta a leitura e o entendimento. É por isso que eu não recomendei isso primeiro.
A maneira mais simples e autodocumentável na sua situação é definir e exportar suas variáveis de ambiente em .profile , conforme descrito acima.
O artigo EnvironmentVariables artigo afirma que é possível modificar o valor de uma variável de ambiente e até mesmo incluir expansões de outras variáveis de ambiente, em .pam_environment , com sintaxe como PATH DEFAULT=${PATH}:${HOME}/MyPrograms . No entanto, isso parece totalmente inconsistente com a (mais) documentação oficial , eu ' Já tentei em várias máquinas sem sucesso, e eu só ouvi falar de falhas para os outros também. Eu suspeito strongmente que o (s) autor (es) wiki (ais) confundiram a sintaxe pam_env "envfile" com pam_env Sintaxe "conffile" (para usar os termos empregados em man pam_env ). Espero que um dia desses alguém consiga descobrir com certeza, e então o wiki pode ser editado (seja para correção ou esclarecimento).
Por que .bash_profile funciona para isso no OS X
O OS X é um dos poucos ambientes / sistemas em que a configuração padrão de terminais em sua área de trabalho gráfica padrão (isto é, instâncias Terminal.app) é para iniciar o shell como um shell de login em vez de um shell de não-login . ( Cygwin é outro.)
Como cada instância do bash no OS X é iniciada diretamente pelo Terminal.app (a menos que você reconfigure as coisas) age como um shell de login, .bash_profile é originado.
Eu suspeito que, fora dos ambientes acessados através do Terminal.app (ou um login não-gráfico, como uma sessão SSH), as exportações em .bash_profile também não são aplicadas.
A principal diferença entre o OS X e o Ubuntu quando se trata de .bash_profile é a seguinte:
-
No OS X, os shells iniciados pelo Terminal.app são iniciados como shells de login. Como o bash é o shell interativo padrão no OS X (desde o OS X 10.3 ou algo assim),
.bash_profileé originado se existir. -
No Ubuntu, quando você executa o Terminal GNOME (ou outro emulador de terminal GUI) de dentro de uma sessão gráfica, o shell é iniciado normalmente não é um shell de login. As tarefas executadas por um shell de login geralmente já foram realizadas (geralmente pelo gerenciador de exibição) para configurar a sessão gráfica, então a ideia é que não há necessidade de realizá-las novamente.
Também é um pouco estranho iniciar um shell de login quando nada que se assemelhe ao login foi feito.