NOTE: the original Subject: header of this thread includes the keyword
"GNOME" which does not appear in the body of the original message, but
which is *terribly* important here. See below.
On Thu, Nov 23, 2023 at 09:49:13AM +0000, Bernhard Walle wrote:
> I want to add some directory to $PATH for each user. In the past, I added a
> file /etc/profile.d/path.sh, but that doesn't work any more, only when I
> manually start bash as login shell (or modify the setting of
> gnome-terminal).
OK, good. You already understand the basics, so we don't need to explain
those in detail.
> My next attempt was to use systemd's /etc/environment.d/path.conf
>
> PATH=${PATH}:/opt/vendor/product/bin
> XPATH=${PATH}:/opt/vendor/product/bin
>
> but that doesn't work either. While XPATH appears, PATH is still the
> default.
>
> systemctl show-environment --user
"systemctl --user" does not show you the environment that a login
session uses. It only shows you the environment that the "per-user
service manager" uses when it starts --user units.
Systemd actually has nothing to do with login session configuration
at all. It's a gigantic dead end.
> To be honest, I'm quite confused where that default path is defined. Even
> when I modify /etc/login.defs (ENV_PATH) or /etc/profile, I still get the
> default value.
/etc/login.defs only works with the login(1) program, which is for the
console. Even then, the value of PATH set by login(1) can and will be
overridden by other programs before you finally get a shell prompt.
Among those overrides are PAM (see pam_env(7)) and your shell (as you
already knew, since you mentioned /etc/profile).
As such, ENV_PATH in /etc/login.defs is pretty much useless. It's never
going to survive to see the light of day, even on a console login. And
it's not used at all by Display Manager (GUI) logins.
Even pam_env ends up being useless for PATH, as the shell overrides it.
It might be useful to set *other* variables, but it's extremely limited.
You can set MYVAR=/some/absolute/path but you *cannot* for example set
MAIL=$HOME/Maildir/ because it will not expand $HOME for you. It's
just so frustatingly inept that you ultimately end up forgetting about
it (but not until you've wasted hours trying to get it to work).
> Of course I can edit my own ~/.bashrc or /etc/bashrc, but that's not what I
> want since then only bash gets the PATH environment, not other shells or
> other programs.
The sad news is that there IS no holy grail here. I've searched for it
myself, as have many other people. It just *does not* exist.
There is no single point of configuration that can customize all user
login sessions, across all login methods, all shells, all desktop
environments, etc.
What ends up happening in practice is that you have to identify *all*
of the configuration points for all of the login methods and shells
that you care about. For console logins with Bourne-family shells,
you can customize a default PATH in /etc/profile (or one of the files
that it dots in). For console logins with csh-family shells, you can
use /etc/csh.login. For Debian X sessions, there is no recommended
global access point, but you can create a ~/.xsessionrc file in your
home directory. I don't know how you do it with Wayland. Nobody who
uses Wayland has ever cared enough to figure it out and publically
announce how to do it (or at least, not here).
Now, I mentioned GNOME at the top of this reply, because GNOME was in the
Subject: header. This is important because GNOME adds one additional
wrinkle to this problem. In a normal X session, there is a single
parent process from which all the other X client processes are spawned.
Getting the correct environment into that parent process is sufficient
to have it propagated into every program that gets launched thereafter.
Usually, creating ~/.xsessionrc (on Debian only, as it's specific to
Debian) will suffice for this, as it gets read in by the X session
before it spawns your window manager, and then the WM spawns everything
else, all with your desired environment. (Again, assuming X, not Wayland.)
Not so with GNOME. In GNOME, all gnome-terminal processes are spawned
by dbus, instead of by the user's X/Wayland session. Therefore,
gnome-terminal and the shell inside it derive from a completely
different ancestry, and come up with a completely different environment.
(And don't even ask me how to configure dbus's environment. I have no
idea.)
So, *specifically* for GNOME, what you end up doing in practice is
precisely the thing you didn't want to do: customizing ~/.bashrc or
~/.cshrc or whatever shell-equivalent RC file, to establish the desired
environment in the shell itself, bypassing whatever crap dbus gives you.
