Установите переменные окружения для gnome на wayland и bash на виртуальных терминалах (или ssh)

13

Gnome 3.22 использует Wayland по умолчанию. Гном на Wayland не читает ~/.profile(или ~/.bash_profileили/etc/profile ). См. Https://bugzilla.gnome.org/show_bug.cgi?id=736660 .

Мои файлы инициализации настроены следующим образом:

  • .bash_profile ничего не делает, кроме источника .profile и.bashrc
  • .profile устанавливает только переменные окружения, такие как PATH иLC_MESSAGES
  • .bashrcустанавливает некоторые специфичные для bash настройки, псевдонимы и переменные среды для таких приложений, как lessиgrep .

Эффект (до Wayland) был следующим:

  • когда я вхожу в систему графически .profileбыл прочитан и переменные среды, как PATHиLC_MESSAGES были установлены. когда я открываю bash внутри эмулятора терминала, тогда .bashrcчитал.
  • когда я вхожу под виртуальным терминалом, то .bash_profileчитается, который в свою очередь читает .profileи .bashrc.
  • когда я захожу с помощью ssh, то поведение похоже на виртуальный терминал.

Во всех случаях .profileи .bashrcбыли прочитаны, и моя среда была создана.

Так что теперь гном 3.22 использует Wayland, а Wayland не читает .profile. Как я могу настроить мои файлы инициализации так, чтобы у меня снова были эффекты, как описано выше?

Обратите внимание, что я не настаиваю на том, что определенные файлы (например, .profile чтении ). Я хочу, чтобы моя среда была настроена разумным образом. Это означает, что я хочу сохранить определенные настройки Bash для файлов инициализации Bash и другие настройки для других файлов инициализации. Также я не хотел бы копировать настройки для разных файлов.

Я использую Arch Linux. Ответы на все рассылки приветствуются. При предложении обходного пути просьба также описать побочные эффекты, а также преимущества и недостатки.


Обновление ноябрь 2017: насколько я понимаю, разработчики GNOME признали, что люди ожидают, что их файлы конфигурации оболочки входа в систему ( .profileи.bash_profile в случае bash) получены после входа в систему. независимо от текстового или графического логина. так что мой вариант использования, изложенный выше, снова работает.

все же разработчики гномов хотят отойти от запуска оболочки входа в систему. похоже, что они идут в направлении использования environmentd из systemd:

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

кажется, что пройдет некоторое время, пока все методы входа не будут адаптированы к среде.

lesmana
источник

Ответы:

7

В Systemd версии 233 (март 2017 г.) добавлена ​​поддержка установки переменных среды в ~/.config/environment.d/*.conf. Смотрите на environment.dстраницу человека и обсуждение , что привело к функции на этом предварительном PR и этой последней единицы .

Джек О'Коннор
источник
это кажется очень хорошим решением. Я сделал быстрый тест. он работает в gnome wayland, но не работает в виртуальном терминале. Я предполагаю, что это также не будет работать для SSH. Я прочитал справочную страницу, но только просмотрел обсуждения. Есть ли у вас идеи, будет ли это также работать в виртуальных терминалах и SSH?
Лесмана
1
Вот хорошее резюме ситуации: in.waw.pl/~zbyszek/blog/environmentd.html . последний абзац говорит, что «виртуальная» поддержка (и ssh?) «может» прийти. по крайней мере, если я правильно понял.
Лесмана
О, интересно, я не осознавал, что GDM должен был добавить специальную поддержку для этого, чтобы это работало. Может ли существовать какая-то договоренность, когда все типы сеансов являются дочерними элементами процесса обслуживания одного пользователя, который уже проанализировал эти env-переменные, и все это просто работает без необходимости GDM / sshd знать что-либо об этом?
Джек О'Коннор
1
Это не работает для меня на Fedora 30 с GDM / Wayland.
Джонлайтон
«Решение» пропускает разумный вариант использования: если A, то установите B. В качестве одного примера, если XDG_SESSION_TYPE = wayland, тогда установите QT_QPA_PLATFORM = wayland.
vk5tu
5

Это обходной путь, который я использую для той же проблемы:

Шаг 1

Создайте исходный скрипт ~/.profileи сделайте его исполняемым. Давайте назовем это /path/to/startup.sh. Это может выглядеть примерно так:

#!/bin/bash
. ~/.profile

Шаг 2

Создайте настольное приложение для запуска скрипта. Для этого вам нужно создать .desktopфайл и поместить его в него ~/.local/share/applications(или, /usr/share/applicationsесли вы хотите, чтобы он работал для всех пользователей). Давайте назовем это ~/.local/share/applications/startup.desktop. Это может выглядеть примерно так:

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

Для получения дополнительной информации о .desktopфайлах смотрите здесь .

Шаг 3

Выйти. Войдите в систему. Теперь вы сможете найти свое приложение в меню приложений.

Шаг 4

Установите это приложение в качестве приложения для запуска. Для этого я использовал Gweme Tweak Tool и добавил свое приложение в список на вкладке Startup Applications.

Вот и все! Теперь вы должны возвращать старую функциональность при каждом входе в систему. Она также сохраняет структуру файла без изменений, поэтому, когда ошибка в Wayland будет исправлена, все, что вам нужно сделать, это удалить приложение из списка запускаемых приложений, удалить два файла. и все возвращается на круги своя.

Позже редактировать

Как отмечает @Guss в комментариях, этот обходной путь не будет экспортировать переменные среды, потому что startup.shон запускается в своей собственной оболочке. Таким образом, нам нужен еще один обходной путь для тех.

Читая документацию GNOME, вы можете увидеть, что есть несколько альтернатив. Единственное, что я мог заставить работать, - это создать файл в/usr/share/gdm/env.d/ и в этом файле поместить переменные для экспорта. Однако это означает, что переменные будут экспортированы для всех пользователей, поэтому я закончил так:

Допустим, у нас есть два пользователя, Джон и Салли . Для каждого из них создайте файл в /usr/share/gdm/env.d/, давайте назовем их startup_john.envи startup_sally.env. В этих файлах поместите переменные среды, которые будут экспортированы, когда они начнут новый сеанс GNOME.

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

На данный момент проблема заключается в том, что оба файла будут загружены для обоих пользователей. Чтобы решить эту проблему, мы устанавливаем разрешение для каждого файла таким образом, чтобы только его владелец мог читать его содержимое.

$ 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

Я согласен, что это не самое элегантное решение, но, насколько я уже проверил, похоже, что дело сделано.

Тудор Виган
источник
Я не проверял это, но он не должен работать, потому что startup.shон работает в своей собственной оболочке и не экспортирует переменные среды в родительский контекст выполнения. В качестве примера, попробуйте запустить этот код в вашей оболочке: echo "a is $a"; (export a="B"); echo "a is $a" . Согласно @Tudor, результат второго эха будет таким a is B, который - вы увидите, когда вы запустите код - не то, что происходит.
Guss
Привет @Guss, ты прав. Я этого не заметил, но теперь, когда вы на это указали, я нашел обходной путь и для переменных среды. Я обновлю свой ответ соответственно.
Тудор Виган,
1
Пожалуйста, сделайте, я хотел бы увидеть, что вы придумали. Кроме того, я думаю, что вы настроены оптимистично, когда говорите «когда ошибка в Wayland исправлена» - это не ошибка в Wayland, а в GNOME, и люди, работающие с GNOME, не считают эту ошибку - это документированное поведение: wiki .gnome.org / Инициативы / Wayland / SessionStart
Guss