Ustaw zmienne środowiskowe dla gnome na wayland i bash na wirtualnych terminalach (lub ssh)

Gnome 3.22 domyślnie używa Waylanda. Gnom na drodze nie czyta ~/.profile( ~/.bash_profileani nie /etc/profile). Zobacz https://bugzilla.gnome.org/show_bug.cgi?id=736660 .

Mam pliki inicjowania skonfigurowane w następujący sposób:

• .bash_profilerobi nic oprócz źródła .profilei.bashrc
• .profileustawia tylko zmienne środowiskowe, takie jak PATHiLC_MESSAGES
• .bashrcustawia niektóre ustawienia i aliasy oraz zmienne środowiskowe specyficzne dla bash dla aplikacji takich jak lessi grep.

Efekt (przed waylandem) był następujący:

• kiedy logowałem się graficznie .profilezostał odczytany i zmienne środowiskowe jak PATHi LC_MESSAGESzostały ustawione. kiedy otworzyłem bash w emulatorze terminala, wtedy .bashrczostał odczytany.
• kiedy loguję się pod wirtualnym terminalem, .bash_profileczytałem, co z kolei czyta .profilei .bashrc.
• kiedy loguję się za pomocą ssh, zachowanie jest podobne do wirtualnego terminala.

We wszystkich przypadkach .profilei .bashrcbyły czytane i moje środowisko została powołana.

Więc teraz gnome 3.22 używa waylanda, a wayland nie czyta .profile. Jak skonfigurować pliki inicjujące, aby ponownie uzyskać efekty opisane powyżej?

Pamiętaj, że nie nalegam, aby niektóre pliki (jak .profile) zostały odczytane. Chcę, aby moje środowisko było skonfigurowane w rozsądny sposób. Oznacza to, że chcę zachować określone ustawienia bash w plikach inicjujących bash, a inne ustawienia w innych plikach inicjujących. Chciałbym również nie kopiować ustawień dla różnych plików.

Używam arch Linux. Odpowiedzi na wszystkie dystrybucje są mile widziane. Sugerując obejście, opisz również skutki uboczne oraz zalety i wady.

Aktualizacja listopad 2017: O ile mi zrozumieć deweloperzy GNOME uznały, że ludzie oczekują swoje pliki konfiguracyjne (shell logowania .profileoraz .bash_profilew przypadku bash) są pozyskiwane po zalogowaniu. niezależnie od tekstu lub graficznego logowania. więc mój opisany powyżej przypadek użycia znów działa.

wciąż programiści gnome chcą odejść od uruchamiania powłoki logowania. wydaje się, że kierunek, w którym zmierzają, to użycie environmentd z systemd:

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

Wydaje się, że minie trochę czasu, zanim wszystkie metody logowania zostaną dostosowane do środowiska.

Wersja systemowa 233 (marzec 2017 r.) Dodała obsługę ustawiania zmiennych środowiskowych w ~/.config/environment.d/*.conf. Zobacz stronę podręcznika environment.dman i dyskusję, która doprowadziła do pojawienia się tego wstępnego PR i ostatniego .

Oto obejście, którego używam dla tego samego problemu:

Krok 1

Utwórz skrypt źródłowy ~/.profilei spraw, aby skrypt był wykonywalny. Nazwijmy to /path/to/startup.sh. Może wyglądać mniej więcej tak:

#!/bin/bash
. ~/.profile

Krok 2

Utwórz aplikację komputerową, aby uruchomić skrypt. Aby to zrobić, musisz utworzyć .desktopplik i umieścić go w ~/.local/share/applications(lub /usr/share/applicationsjeśli chcesz, aby działał dla wszystkich użytkowników). Nazwijmy to ~/.local/share/applications/startup.desktop. Może wyglądać mniej więcej tak:

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

Aby uzyskać więcej informacji o .desktopplikach, zobacz tutaj .

Krok 3

Wyloguj. Zaloguj się ponownie. Teraz powinieneś być w stanie wyszukać swoją aplikację w menu aplikacji.

Krok 4

Ustaw tę aplikację jako aplikację startową. Aby to zrobić, użyłem narzędzia Gnome Tweak Tool i dodałem swoją aplikację do listy w zakładce Aplikacje startowe.

I to wszystko! Powinieneś teraz przywracać starą funkcjonalność przy każdym logowaniu. Zachowuje również nienaruszoną strukturę plików, więc gdy błąd w Wayland zostanie naprawiony, wszystko, co musisz zrobić, to usunąć aplikację z listy aplikacji startowych, usunąć dwa pliki i wszystko wróciło do normy.

Później edytuj

Jak wskazuje @Guss w komentarzach, to obejście nie wyeksportuje zmiennych środowiskowych, ponieważ startup.shjest uruchamiane we własnej powłoce. Potrzebujemy więc innego rozwiązania tego problemu.

Czytając z dokumentacji GNOME , możesz zobaczyć, że istnieje kilka alternatyw. Jedyne, co mogłem dostać do pracy, to utworzenie pliku /usr/share/gdm/env.d/i umieszczenie w nim zmiennych, które mają zostać wyeksportowane. Oznacza to jednak, że zmienne zostaną wyeksportowane dla wszystkich użytkowników, więc skończyłem tak:

Załóżmy, że mamy dwóch użytkowników, Johna i Sally . Dla każdego z nich utwórz plik /usr/share/gdm/env.d/, nazwijmy je startup_john.envi startup_sally.env. W tych plikach umieść zmienne środowiskowe, które mają zostać wyeksportowane po rozpoczęciu nowej sesji GNOME.

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

W tym momencie problem polega na tym, że oba pliki zostaną załadowane dla obu użytkowników. Aby rozwiązać ten problem, ustawiamy uprawnienia do każdego pliku, tak aby tylko jego właściciel mógł czytać jego zawartość.

$ 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

Zgadzam się, że nie jest to najbardziej eleganckie rozwiązanie, ale o ile testowałem, wydaje się, że wykonało to zadanie.