On Fri, Nov 24, 2023 at 11:51:53PM +0700, Max Nikulin wrote: > I guess you are not running Gnome.
I'm using fvwm. > A window manager still might do some magic by calling "systemctl > set-environment". My impression is that nowadays an application spawned by > systemd is not something unusual. The world is definitely changing, and user sessions are becoming more diverse and more complex. I certainly don't understand all of the cases in use today. > I experimented a bit with KDE and SDDM (I do not have a Gnome VM ready for > tests). Terminal applications (konsole, xterm) are started as children of > systemd user session, not startplasma that is spawned by the display > manager. So /etc/environment.d and ~/.config/environment.d *affect* > environment of shell in terminal applications. Well, that's new to me, and very interesting. I can't say whether it's a good or bad change, but it's good to know about it. > On the other hand I can not say that I understand what happens with PATH. > Likely modifications made through environment.d are overwritten by > /etc/profile. The latter is called by /etc/sddm/Xsession (or > wayland-session). /etc/profile is only read by login shells of the Bourne family, unless something goes out of its way to read that file explicitly. Does KDE spawn login shells instead of regular ones? > I am puzzled why neither environment.d nor /etc/profile works in the case of > the topic starter. I suspect a typo somewhere. I am unsure if various bugs > like https://github.com/systemd/systemd/issues/6414 are relevant. My reading was that /etc/profile *would* work for them, if they reconfigured their desktop environment to launch login shells instead of regular shells, but that isn't what they want to do. They also pointed out that /etc/bash.bashrc or ~/.bashrc would work, but only for bash, whereas they were looking for something independent of the user's shell. > Just a reminder: BASH does not read ~/.profile if ~/.bash_login or > ~/.bash_profile exists. And none of them are read by regular shells. Those read ~/.bashrc instead. > You post is great in respect to details concerning current state of affairs. > I tried to ask if you see a way to make configuration easier for users. E.g. > /etc/profile is suitable when a shell is involved. It was fine decades ago, > but display managers may start sessions bypassing shells. Perhaps > environment.d may be sourced by shells in the case of console login and > xinit. I still hope that it is possible to create a single point for > environment configuration and to provide helper tools for various ways to > login. The way everything is diversifying right now, it appears that the situation is going to become more complicated, not simpler, in the next few years/decades. If *simple* and *consistent* user configuration across session types and shells is a goal that any of the desktop environment authors care about, they need to talk to each other and come up with *one* scheme that they can all agree on, and implement that. I've yet to see any evidence that this is a priority for them. Even if they do come up with one scheme and implement it, we'll still have legacy environments (like fvwm and fluxbox, presumably) that won't use it. And of course direct login shells (console, ssh) will remain separate entities.
