Defina variáveis ​​de ambiente para o gnome no wayland e bash nos terminais virtuais (ou ssh)

O Gnome 3.22 usa wayland por padrão. O gnomo no wayland não lê ~/.profile(ou ~/.bash_profileou /etc/profile). Consulte https://bugzilla.gnome.org/show_bug.cgi?id=736660 .

Eu tenho meus arquivos de inicialização configurados da seguinte maneira:

• .bash_profilenão faz nada além de fonte .profilee.bashrc
• .profiledefine apenas variáveis ​​de ambiente como PATHeLC_MESSAGES
• .bashrcdefine algumas configurações e aliases específicos do bash e variáveis ​​de ambiente para aplicativos como lesse grep.

O efeito (antes do wayland) foi o seguinte:

• quando eu logar graficamente .profileera lido e variáveis ​​de ambiente como PATHe LC_MESSAGESforam definidas. quando abro o bash dentro de um emulador de terminal, então .bashrcera lido.
• quando eu entrar em um terminal virtual, em seguida, .bash_profilefoi lido, que por sua vez lê .profilee .bashrc.
• quando eu faço login usando ssh, o comportamento é semelhante ao terminal virtual.

Em todos os casos .profilee .bashrcfoi lida e meu ambiente foi criado.

Então agora o 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 eu não insisto que certos arquivos (como .profile) sejam lidos. O que eu quero é que meu ambiente seja configurado de maneira sensata. Isso significa que quero manter configurações específicas do bash nos arquivos de inicialização do bash e outras configurações em 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 também os efeitos colaterais e as vantagens e desvantagens.

atualização novembro de 2017: pelo que entendi, os desenvolvedores do gnome reconheceram que as pessoas esperam que seus arquivos de configuração do shell de login ( .profilee .bash_profileno caso do bash) sejam originados após o login. independentemente do texto ou login gráfico. portanto, meu caso de uso descrito acima funciona novamente.

ainda assim, os desenvolvedores do gnome querem deixar de iniciar um shell de login. parece que a direção que eles estão seguindo é usar o environmentd do systemd:

https://in.waw.pl/~zbyszek/blog/environmentd.html

parece que levará um tempo até que todos os métodos de login sejam adaptados ao environmentd.

O Systemd versão 233 (março de 2017) adicionou suporte para a configuração de variáveis ​​de ambiente no ~/.config/environment.d/*.conf. Veja a environment.dpágina de manual e a discussão que levou ao recurso neste PR preliminar e neste final .

Esta é a solução alternativa que eu uso exatamente para o mesmo problema:

Passo 1

Crie um script que origine ~/.profilee torne esse script executável. Vamos chamá-lo /path/to/startup.sh. Pode ser algo como isto:

#!/bin/bash
. ~/.profile

Passo 2

Crie um aplicativo da área de trabalho para executar o script. Para fazer isso, você precisa criar um .desktoparquivo e colocá-lo ~/.local/share/applications(ou /usr/share/applicationsse desejar que ele funcione para todos os usuários). Vamos chamá-lo ~/.local/share/applications/startup.desktop. Pode ser algo como isto:

[Desktop Entry]
Name=Startup
Keywords=startup
Exec=/path/to/startup.sh
Type=Application

Para mais informações sobre .desktoparquivos, clique aqui .

etapa 3

Sair. Faça login novamente. Agora você deve poder procurar seu aplicativo no menu de aplicativos.

Passo 4

Defina este aplicativo como um aplicativo de inicialização. Para fazer isso, usei a Ferramenta Gnome Tweak e adicionei meu aplicativo à lista na guia Aplicativos de inicialização.

E é isso! Agora você deve recuperar sua funcionalidade antiga sempre que efetuar login. Também preserva a estrutura do arquivo intacta; portanto, quando o bug no Wayland é corrigido, basta remover o aplicativo da lista de aplicativos de inicialização e excluir os dois arquivos. e tudo voltou ao normal.

Edição posterior

Como o @Guss aponta nos comentários, essa solução alternativa não exportará variáveis ​​de ambiente porque startup.shé executada em seu próprio shell. Então, precisamos de outra solução alternativa para eles.

Lendo a documentação do GNOME, você pode ver que existem algumas alternativas. O único que eu pude trabalhar foi criar um arquivo /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 é o seguinte:

Digamos que temos dois usuários, john e sally . Para cada um deles criar um arquivo /usr/share/gdm/env.d/, vamos chamá-los startup_john.enve startup_sally.env. Nesses arquivos, coloque as variáveis ​​de ambiente a serem exportadas quando iniciarem uma nova sessão do GNOME.

$ cat startup_john.env
VAR=1
$ cat startup_sally.env
VAR=2

Neste ponto, o problema é que os dois arquivos serão carregados para os dois usuários. Para resolver isso, definimos a permissão em cada arquivo, de modo que somente seu 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 fazer o trabalho.