O Gnome 3.22 usa wayland por padrão. O Gnome on wayland não lê ~/.profile (ou ~/.bash_profile ou /etc/profile ). Consulte o link .
Eu tenho meus arquivos de inicialização configurados da seguinte forma:
.bash_profile não faz nada além da fonte .profile e .bashrc
.profile apenas define variáveis de ambiente como PATH e LC_MESSAGES
.bashrc define algumas configurações e aliases específicos do bash e variáveis de ambiente para aplicativos como less e grep . O efeito (antes do caminho) foi o seguinte:
.profile foi lido e variáveis de ambiente como PATH e LC_MESSAGES foram definidas. quando eu abro bash dentro de um emulador de terminal, então .bashrc foi lido. .bash_profile foi lido, o que, por sua vez, mostra .profile e .bashrc . Em todos os casos .profile e .bashrc foram lidos e meu ambiente foi configurado.
Então agora gnome 3.22 usa wayland e wayland não lê .profile . Como posso configurar meus arquivos de inicialização para que eu tenha novamente os efeitos descritos acima?
Note que não insisto que certos arquivos (como .profile ) sejam lidos. O que eu quero é ter meu ambiente organizado de uma maneira sensata. Isso significa que eu quero manter as configurações específicas do bash nos arquivos de inicialização do bash e outras configurações para outros arquivos de inicialização. Também gostaria de não copiar as configurações em arquivos diferentes.
Eu uso o arch linux. Respostas para todas as distribuições são bem vindas. Ao sugerir uma solução alternativa, descreva os efeitos colaterais e as vantagens e desvantagens.
atualização novembro de 2017: até onde eu sei, os desenvolvedores do gnome reconheceram que as pessoas esperam que seus arquivos de configuração do shell de login ( .profile e .bash_profile no caso do bash) sejam originados após o login. independentemente de texto ou login gráfico. então meu caso de uso descrito acima funciona novamente.
os desenvolvedores do gnome ainda querem se afastar de iniciar um shell de login. parece que a direção que eles estão indo é usar o environmentd do systemd:
parece que vai demorar um pouco até que todos os métodos de login sejam adaptados ao ambiente.
A versão 233 do Systemd (março de 2017) adicionou suporte para a configuração de variáveis de ambiente em ~/.config/environment.d/*.conf . Consulte a página environment.d man e a discussão que levou ao recurso este PR preliminar e este final .
Esta é a solução alternativa que uso para o mesmo problema:
Crie um script que origine ~/.profile e torne esse script executável. Vamos chamá-lo de /path/to/startup.sh . Poderia ser algo assim:
#!/bin/bash
. ~/.profile
Crie um aplicativo de desktop para executar o script. Para fazer isso, você precisa criar um arquivo .desktop e colocá-lo em ~/.local/share/applications (ou /usr/share/applications se quiser que funcione para todos os usuários). Vamos chamá-lo de ~/.local/share/applications/startup.desktop . Poderia ser algo assim:
[Desktop Entry]
Name=Startup
Keywords=startup
Exec=/path/to/startup.sh
Type=Application
Para obter mais informações sobre os arquivos .desktop , consulte aqui .
Faça logout. Faça o login novamente. Agora você deve poder pesquisar seu aplicativo no menu de aplicativos.
Defina este aplicativo como um aplicativo de inicialização. Para fazer isso, usei a Gnome Tweak Tool e adicionei meu aplicativo à lista na guia Aplicativos de inicialização.
E é isso! Agora você deve ter sua funcionalidade antiga de volta sempre que fizer login. Ela também preserva a estrutura do arquivo intacta, portanto, quando o bug no Wayland for corrigido, tudo o que você precisa remover o aplicativo da lista de aplicativos de inicialização, exclua os dois arquivos e tudo voltou ao normal.
Como aponta @Guss nos comentários, essa solução alternativa não exportará variáveis de ambiente porque startup.sh é executado em seu próprio shell. Então, precisamos de outra solução alternativa para eles.
Ao ler a documentação do GNOME , você pode ver que existem algumas alternativas. O único que consegui trabalhar foi criar um arquivo em /usr/share/gdm/env.d/ e, nesse arquivo, colocar as variáveis a serem exportadas. No entanto, isso significa que as variáveis serão exportadas para todos os usuários, então o que acabei fazendo é isso:
Digamos que temos dois usuários, joão e sally . Para cada um deles, crie um arquivo em /usr/share/gdm/env.d/ , vamos chamá-lo de startup_john.env e startup_sally.env . Nesses arquivos, coloque as variáveis de ambiente a serem exportadas quando elas iniciarem uma nova sessão do GNOME.
$ cat startup_john.env
VAR=1
$ cat startup_sally.env
VAR=2
Neste ponto, o problema é que ambos os arquivos serão carregados para ambos os usuários. Para resolver isso, definimos a permissão em cada arquivo de forma que apenas o proprietário possa ler seu conteúdo.
$ ls -l startup_john.env
-rw-r-----. 1 john john 4 Dec 27 15:17 startup_john.env
$ ls -l startup_sally.env
-rw-r-----. 1 sally sally 4 Dec 27 15:16 startup_sally.env
Não é a solução mais elegante, eu concordo, mas, até onde eu testei, parece que o trabalho é feito.