Gnome 3.22 domyślnie używa Waylanda. Gnom na drodze nie czyta ~/.profile
( ~/.bash_profile
ani nie /etc/profile
). Zobacz https://bugzilla.gnome.org/show_bug.cgi?id=736660 .
Mam pliki inicjowania skonfigurowane w następujący sposób:
.bash_profile
robi nic oprócz źródła.profile
i.bashrc
.profile
ustawia tylko zmienne środowiskowe, takie jakPATH
iLC_MESSAGES
.bashrc
ustawia niektóre ustawienia i aliasy oraz zmienne środowiskowe specyficzne dla bash dla aplikacji takich jakless
igrep
.
Efekt (przed waylandem) był następujący:
- kiedy logowałem się graficznie
.profile
został odczytany i zmienne środowiskowe jakPATH
iLC_MESSAGES
zostały ustawione. kiedy otworzyłem bash w emulatorze terminala, wtedy.bashrc
został odczytany. - kiedy loguję się pod wirtualnym terminalem,
.bash_profile
czytałem, co z kolei czyta.profile
i.bashrc
. - kiedy loguję się za pomocą ssh, zachowanie jest podobne do wirtualnego terminala.
We wszystkich przypadkach .profile
i .bashrc
był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 .profile
oraz .bash_profile
w 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.
źródło
Oto obejście, którego używam dla tego samego problemu:
Krok 1
Utwórz skrypt źródłowy
~/.profile
i spraw, aby skrypt był wykonywalny. Nazwijmy to/path/to/startup.sh
. Może wyglądać mniej więcej tak:Krok 2
Utwórz aplikację komputerową, aby uruchomić skrypt. Aby to zrobić, musisz utworzyć
.desktop
plik i umieścić go w~/.local/share/applications
(lub/usr/share/applications
jeś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:Aby uzyskać więcej informacji o
.desktop
plikach, 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.sh
jest 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 jestartup_john.env
istartup_sally.env
. W tych plikach umieść zmienne środowiskowe, które mają zostać wyeksportowane po rozpoczęciu nowej sesji GNOME.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ść.
Zgadzam się, że nie jest to najbardziej eleganckie rozwiązanie, ale o ile testowałem, wydaje się, że wykonało to zadanie.
źródło
startup.sh
działa ono w swojej własnej powłoce i nie eksportuje zmiennych środowiskowych do nadrzędnego kontekstu wykonania. Jako przykład, spróbuj uruchomić ten kod w swojej powłoce:echo "a is $a"; (export a="B"); echo "a is $a"
. Według @Tudora, wyjście drugiego echa będziea is B
, co - zobaczysz po uruchomieniu kodu - nie jest tym, co się dzieje.