Setze Umgebungsvariablen für Gnome auf Wayland und Bash auf virtuellen Terminals (oder ssh)

Gnome 3.22 verwendet standardmäßig Wayland. Gnome auf Wayland liest nicht ~/.profile(oder ~/.bash_profileoder /etc/profile). Siehe https://bugzilla.gnome.org/show_bug.cgi?id=736660 .

Ich habe meine Initialisierungsdateien wie folgt eingerichtet:

• .bash_profiletut nichts anderes als quelle .profileund.bashrc
• .profileSetzt nur Umgebungsvariablen wie PATHundLC_MESSAGES
• .bashrcLegt einige bash-spezifische Einstellungen sowie Aliase und Umgebungsvariablen für Anwendungen wie lessund fest grep.

Der Effekt (vor Wayland) war folgender:

• beim einloggen wurde grafisch .profilegelesen und umgebungsvariablen wie PATHund LC_MESSAGESgesetzt. wenn ich bash in einem terminalemulator öffne wurde dann .bashrcgelesen.
• wenn ich mich unter einem virtuellen terminal anmelde .bash_profilewurde dann gelesen was wiederum liest .profileund .bashrc.
• Wenn ich mich mit ssh anmelde, ähnelt das Verhalten dem des virtuellen Terminals.

In allen Fällen .profileund .bashrcwurden gelesen und meine Umgebung eingerichtet.

Also benutzt Gnome 3.22 Wayland und Wayland liest nicht .profile. Wie kann ich meine Initialisierungsdateien so einrichten, dass ich wieder die oben beschriebenen Auswirkungen habe?

Beachten Sie, dass ich nicht darauf bestehe, dass bestimmte Dateien (wie .profile) gelesen werden. Ich möchte, dass meine Umgebung auf vernünftige Weise eingerichtet wird. Das heißt, ich möchte die bash-spezifischen Einstellungen für die bash-Initialisierungsdateien und andere Einstellungen für andere Initialisierungsdateien beibehalten. Auch möchte ich die Einstellungen nicht über verschiedene Dateien kopieren.

Ich benutze Arch Linux. Antworten für alle Distributionen sind willkommen. Wenn Sie eine Problemumgehung vorschlagen, beschreiben Sie bitte auch die Nebenwirkungen sowie die Vor- und Nachteile.

Update November 2017: Soweit ich weiß, haben die Gnome-Entwickler bestätigt, dass die Benutzer erwarten, dass ihre Login-Shell-Konfigurationsdateien ( .profileund .bash_profileim Falle von Bash) nach dem Login bezogen werden. unabhängig von Text oder grafischer Anmeldung. Mein oben beschriebener Anwendungsfall funktioniert also wieder.

Trotzdem möchten die Gnome-Entwickler nicht mehr eine Login-Shell starten. Es scheint, dass die Richtung, in die sie gehen, darin besteht, environmentd von systemd zu verwenden:

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

Es scheint, dass es eine Weile dauern wird, bis alle Anmeldemethoden an environmentd angepasst sind.

Systemd Version 233 (März 2017) unterstützt jetzt das Setzen von Umgebungsvariablen in ~/.config/environment.d/*.conf. Siehe die environment.dManpage und die Diskussion, die zu dem Feature dieser vorläufigen und dieser letzten PR geführt hat .

Dies ist die Problemumgehung, die ich für genau das gleiche Problem verwende:

Schritt 1

Erstellen Sie ein Skript, das als Quelle dient, ~/.profileund machen Sie dieses Skript ausführbar. Nennen wir es /path/to/startup.sh. Es könnte ungefähr so ​​aussehen:

#!/bin/bash
. ~/.profile

Schritt 2

Erstellen Sie eine Desktop-Anwendung, um das Skript auszuführen. Dazu müssen Sie eine .desktopDatei erstellen und in diese einfügen ~/.local/share/applications(oder /usr/share/applicationswenn Sie möchten, dass sie für alle Benutzer funktioniert). Nennen wir es ~/.local/share/applications/startup.desktop. Es könnte ungefähr so ​​aussehen:

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

Weitere Informationen zu .desktopDateien finden Sie hier .

Schritt 3

Ausloggen. Melden Sie sich erneut an. Sie sollten nun in der Lage sein, im Anwendungsmenü nach Ihrer Anwendung zu suchen.

Schritt 4

Legen Sie diese Anwendung als Startanwendung fest. Dazu habe ich das Gnome Tweak Tool verwendet und meine Anwendung der Liste auf der Registerkarte Startup Applications hinzugefügt.

Und das ist es! Sie sollten jetzt Ihre alte Funktionalität wieder haben, wenn Sie sich anmelden. Sie behält auch die Dateistruktur bei. Wenn der Fehler in Wayland behoben ist, müssen Sie die Anwendung nur aus der Liste der Startanwendungen entfernen und die beiden Dateien löschen und alles ist wieder normal.

Später bearbeiten

Wie @Guss in den Kommentaren ausführt, werden bei dieser Problemumgehung keine Umgebungsvariablen exportiert, da startup.shsie in einer eigenen Shell ausgeführt werden. Wir brauchen also eine andere Lösung für diese Probleme.

Aus der GNOME-Dokumentation können Sie ersehen, dass es einige Alternativen gibt. Das einzige, was ich zur Arbeit bringen konnte, war, eine Datei zu erstellen /usr/share/gdm/env.d/und in dieser Datei die zu exportierenden Variablen abzulegen. Dies bedeutet jedoch, dass die Variablen für alle Benutzer exportiert werden. Am Ende habe ich Folgendes getan:

Nehmen wir an, wir haben zwei Benutzer, John und Sally . Für jede von ihnen erstellen Sie eine Datei in /usr/share/gdm/env.d/, nennen wir sie startup_john.envund startup_sally.env. Platzieren Sie in diesen Dateien die Umgebungsvariablen, die exportiert werden sollen, wenn Sie eine neue GNOME-Sitzung starten.

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

Zu diesem Zeitpunkt besteht das Problem darin, dass beide Dateien für beide Benutzer geladen werden. Um dieses Problem zu lösen, setzen wir die Berechtigung für jede Datei so, dass nur der Eigentümer den Inhalt lesen kann.

$ 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

Ich bin damit einverstanden, dass dies nicht die eleganteste Lösung ist, aber soweit ich es getestet habe, scheint es die Arbeit zu erledigen.