Définir les variables d'environnement pour gnome sur wayland et bash sur les terminaux virtuels (ou ssh)

Gnome 3.22 utilise wayland par défaut. Gnome sur wayland ne lit pas ~/.profile(ou ~/.bash_profileou /etc/profile). Voir https://bugzilla.gnome.org/show_bug.cgi?id=736660 .

J'ai mes fichiers d'initialisation configurés comme suit:

• .bash_profilene fait que source .profileet.bashrc
• .profilene définit que les variables d'environnement comme PATHetLC_MESSAGES
• .bashrcdéfinit certains paramètres et alias spécifiques à bash et des variables d'environnement pour des applications telles que lesset grep.

L'effet (avant Wayland) était le suivant:

• lorsque je me connecte graphiquement a .profileété lu et les variables d'environnement comme PATHet LC_MESSAGESont été définies. lorsque j'ouvre bash à l'intérieur d'un émulateur de terminal, j'ai .bashrcété lu.
• lorsque je me connecte sous un terminal virtuel, puis a .bash_profileété lu qui à son tour lit .profileet .bashrc.
• lorsque je me connecte en utilisant ssh, le comportement est similaire au terminal virtuel.

Dans tous les cas .profileet .bashrcont été lus et mon environnement a été mis en place.

Alors maintenant, gnome 3.22 utilise wayland et wayland ne lit pas .profile. Comment puis-je configurer mes fichiers d'initialisation pour que je retrouve les effets décrits ci-dessus?

Notez que je n'insiste pas pour que certains fichiers (comme .profile) soient lus. Ce que je veux, c'est que mon environnement soit configuré de manière sensée. Cela signifie que je souhaite conserver des paramètres spécifiques à bash dans les fichiers d'initialisation bash et d'autres paramètres dans d'autres fichiers d'initialisation. Je voudrais également ne pas copier les paramètres sur différents fichiers.

J'utilise arch linux. Les réponses à toutes les distributions sont les bienvenues. Lorsque vous proposez une solution de contournement, veuillez également décrire les effets secondaires ainsi que les avantages et les inconvénients.

mise à jour de novembre 2017: pour autant que je sache, les développeurs de gnome ont reconnu que les gens s'attendent à ce que leurs fichiers de configuration du shell de connexion ( .profileet .bash_profileen cas de bash) proviennent de la connexion. indépendamment du texte ou de la connexion graphique. donc mon cas d'utilisation décrit ci-dessus fonctionne à nouveau.

les développeurs de gnome veulent toujours s'éloigner du démarrage d'un shell de connexion. il semble que la direction qu'ils vont est d'utiliser environnementd à partir de systemd:

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

il semble que cela prendra un certain temps avant que toutes les méthodes de connexion soient adaptées à environmentd.

Systemd version 233 (mars 2017) a ajouté la prise en charge de la définition des variables d'environnement dans ~/.config/environment.d/*.conf. Voir la environment.dpage de manuel et la discussion qui a conduit à la fonctionnalité de ce PR préliminaire et de cette dernière .

C'est la solution de contournement que j'utilise pour exactement le même problème:

Étape 1

Créez un script qui source ~/.profileet rendez ce script exécutable. Appelons ça /path/to/startup.sh. Cela pourrait ressembler à ceci:

#!/bin/bash
. ~/.profile

Étape 2

Créez une application de bureau pour exécuter le script. Pour ce faire, vous devez créer un .desktopfichier et le placer ~/.local/share/applications(ou /usr/share/applicationssi vous souhaitez qu'il fonctionne pour tous les utilisateurs). Appelons ça ~/.local/share/applications/startup.desktop. Cela pourrait ressembler à ceci:

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

Pour plus d'informations sur les .desktopfichiers, voir ici .

Étape 3

Se déconnecter. Reconnectez-vous. Vous devriez maintenant pouvoir rechercher votre application dans le menu des applications.

Étape 4

Définissez cette application comme application de démarrage. Pour ce faire, j'ai utilisé l'outil Gnome Tweak et ajouté mon application à la liste dans l'onglet Applications de démarrage.

Et c'est tout! Vous devriez maintenant avoir votre ancienne fonctionnalité à chaque fois que vous vous connectez. Elle préserve également la structure du fichier, donc, lorsque le bogue de Wayland est corrigé, tout ce dont vous avez besoin pour le faire, supprimez l'application de la liste des applications de démarrage, supprimez les deux fichiers et tout est revenu à la normale.

Modification ultérieure

Comme @Guss le fait remarquer dans les commentaires, cette solution de contournement n'exportera pas les variables d'environnement car elle startup.shest exécutée dans son propre shell. Nous avons donc besoin d'une autre solution de contournement pour ceux-ci.

En lisant la documentation GNOME, vous pouvez voir qu'il existe quelques alternatives. Le seul que j'ai pu travailler était de créer un fichier /usr/share/gdm/env.d/et, dans ce fichier, de placer les variables à exporter. Cependant, cela signifie que les variables seront exportées pour tous les utilisateurs, donc ce que j'ai fini par faire est le suivant:

Disons que nous avons deux utilisateurs, John et Sally . Pour chacun d'eux créer un fichier dans /usr/share/gdm/env.d/, appelons-les startup_john.envet startup_sally.env. Dans ces fichiers, placez les variables d'environnement à exporter au démarrage d'une nouvelle session GNOME.

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

À ce stade, le problème est que les deux fichiers seront chargés pour les deux utilisateurs. Afin de résoudre ce problème, nous définissons l'autorisation sur chaque fichier de sorte que seul son propriétaire puisse lire son contenu.

$ 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

Ce n'est pas la solution la plus élégante, je suis d'accord, mais, pour autant que j'aie testé, elle semble faire le travail.