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

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

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

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

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

Шаг 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

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