Область переменных окружения

Ранее я думал, что переменные окружения определяются в области процесса, и если они экспортируются, то передаются дочерним процессам.

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

1. Сервиса пользователя, определенного в ~/.config/systemd/user/start-up.service
2. Файла hyprland.conf
3. Оболочки ZSH

Я использую Arch Linux с SDDM, Hyprland, терминалом Kitty и оболочкой ZSH. Я попробовал несколько решений, и единственным работающим был вариант определения переменных окружения в файле hyprland.conf (на самом деле, во внешнем файле, подключаемом Hyprland), и иметь дублирующее определение для двух переменных окружения, необходимых сервису, в поле Environment сервиса. Я не могу использовать EnvironmentFile, так как между форматами, ожидаемыми Hyprland и файлами сервисов, существует несоответствие. Мне не нравится это решение из-за дублирования.

Но в процессе моего исследования я обнаружил очень неожиданную вещь: все переменные окружения, определенные в hyprland.conf, видны в оболочке ZSH, хотя оболочка не является дочерним процессом Hyprland.

pstree
systemd─┬─NetworkManager───4*[{NetworkManager}]
        ├─dbus-daemon
   ==>  ├─kitty─┬─zsh───pstree
        │       └─2*[{kitty}]
        ├─polkitd───3*[{polkitd}]
        ├─rtkit-daemon───2*[{rtkit-daemon}]
        ├─sddm─┬─Xorg───2*[{Xorg}]
   ==>  │      ├─sddm-helper───Hyprland───4*[{Hyprland}]
        │      └─{sddm}
        ├─sh───sleep
        ├─ssh-agent
        ├─systemd─┬─(sd-pam)
        │         ├─dbus-daemon
        │         ├─gnome-keyring-d───4*[{gnome-keyring-d}]
        │         ├─pipewire───2*[{pipewire}]
        │         ├─pipewire-pulse───2*[{pipewire-pulse}]
        │         ├─wireplumber───6*[{wireplumber}]
        │         ├─2*[xdg-desktop-por───4*[{xdg-desktop-por}]]
        │         ├─xdg-document-po─┬─fusermount3
        │         │                 └─6*[{xdg-document-po}]
        │         └─xdg-permission-───3*[{xdg-permission-}]
        ├─systemd-journal
        ├─systemd-logind
        ├─systemd-timesyn───{systemd-timesyn}
        ├─systemd-udevd
        ├─upowerd───3*[{upowerd}]
        └─wpa_supplicant

Таким образом, у меня на самом деле два вопроса:

1. Существует ли единственное место для определения переменных окружения (которые должны определяться на уровне пользователя, а не системы), чтобы они были видны для сервиса пользователя, Hyprland и оболочки?
2. Как возможно, что переменные, определенные в hyprland.conf, видны его дочернему процессу?

Я наткнулся на этот вопрос, пытаясь разобраться с настройкой PATH в swaywm, поэтому думаю, что наши мотивы схожи. Я не являюсь экспертом в POSIX или C, но вот что я думаю после прочтения соответствующих страниц руководства и исходного кода GLIBC (поправки приветствуются):

1. “Окружение” – это строка специфичная для каждого процесса. Вы можете узнать, с чем процесс был создан из /proc/(pid)/environ, но это не означает, что строка не была изменена с тех пор.

2. Когда программа использует GLIBC, новые процессы инициируются с помощью семейства функций C exec. Некоторые из них неявно копируют переменную environ для новых процессов, некоторые позволяют передать новую в качестве аргумента (например, execle и т.д.). С этого момента два процесса не разделяют окружение. Таким образом, дочерний процесс может получить окружение родительского процесса, но после этого, если родитель изменяет свое собственное (например, с помощью setenv), окружение дочернего процесса останется неизменным.

3. В Unix/Linux нет “глобального окружения”. Это просто процессы, передающие спецификации окружения своим детям. Существуют механизмы для чтения переменных окружения в определенный момент (например, см. вики Arch), но это всего лишь соглашения.

4. Оболочки ведут список переменных, который отличается от их environ. В большинстве оболочек export FOO просто означает “добавить FOO к environ при запуске новых процессов.”

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