I wish this article actually answered the titular question.
$PATH is a session-wide resource. You are not supposed to configure it through your shell rc files as if it was just another interactive shell eye-candy thing. Or, in other words that would likely “click” better with certain parts of audience — you’re binding this resource to the wrong scope and the wrong lifetime.
Before systemd, you would configure $PATH via the “profile” files: ~/.profile, ~/.bash_profile (an unfortunate scope mix-up, yes), or /etc/profile. If you use an X11 session, chances are, these files are still honored, because the start-up sequence of Xorg goes through the shell and it is usually written to source these files somewhere in the Xsession script.
With systemd --user and the shell-less startup path of Wayland compositors, it’s harder to make actual session-scoped adjustments to the environment.
There are two ways, though: either 1) PAM (pam_env.so), but it is deprecated, or 2) co-opt systemd --user to import your preferred source of environment into systemd’s own environment, and watch as it naturally trickles everywhere else: import-profile.service.
The downside to systemd method is that you’re adjusting the systemd pseudo-session, not your actual session. So if you log in via tty, it won’t work. I use tmux pervasively with the server being launched as a systemd --user unit (and for the GUI part, I use GNOME which runs the entire thing under systemd --user), so it works out in the end.
If I used true tty sessions that are not linked to systemd --user, I’d write some small script to backfill the environment from systemd to the tty session and stuck it into the shell profile script (with appropriate safeguards to avoid recursion).
TL;DR: it’s much harder than it should be, and unfortunately, the article does not seem to provide an actual true answer.
This is the part where your neighborhood Nushell zealot mentions how nice editing its path config is. The out-of-the box config comes with a tidy list of piped prepend commands ending in a uniq command to remove accidental duplicates.
I’m honestly not sure how to handle it in an IDE/GUI because I haven’t run into that in a long time, will add directions here if someone points me in the right direction.
Directions I can provide. Wish I could point to “the right one”. Empirically ~/.profile has worked for me lately across distros (Debian/Wayland/Plasma, Ubuntu/Wayland/Plasma, Ubuntu/X11/GNOME; edit: openSUSE/Wayland/Plasma) but I have blind spots (been a while since I tried XFCE. Also, I wonder how hard Nix users are laughing).
I don’t think fd.o covers this? But I might have missed something.
That’s interpreting the prompt as “Amending PATH for the whole graphical session”; interpreting it as “Amending PATH for specific IDE/GUI programs”, … oof.
See that program’s manual? Emacs has exec-path, I dimly remember some IDEs automatically sourcing shell dotfiles (or just spawning shells) to ensure tools work according to user expectations?
If you’re not sure what shell you’re using, here’s a way to find out. Run this:
ps -p $$ -o pid,comm=
I’ve always used echo $0 to figure out the shell I’m currently in. But I’ve only ever used unix sh-like shells, so I’m not sure if that works in fish and others.
I wish this article actually answered the titular question.
$PATHis a session-wide resource. You are not supposed to configure it through your shell rc files as if it was just another interactive shell eye-candy thing. Or, in other words that would likely “click” better with certain parts of audience — you’re binding this resource to the wrong scope and the wrong lifetime.Before systemd, you would configure
$PATHvia the “profile” files:~/.profile,~/.bash_profile(an unfortunate scope mix-up, yes), or/etc/profile. If you use an X11 session, chances are, these files are still honored, because the start-up sequence of Xorg goes through the shell and it is usually written to source these files somewhere in the Xsession script.With
systemd --userand the shell-less startup path of Wayland compositors, it’s harder to make actual session-scoped adjustments to the environment.There are two ways, though: either 1) PAM (
pam_env.so), but it is deprecated, or 2) co-optsystemd --userto import your preferred source of environment into systemd’s own environment, and watch as it naturally trickles everywhere else:import-profile.service.The downside to systemd method is that you’re adjusting the systemd pseudo-session, not your actual session. So if you log in via tty, it won’t work. I use
tmuxpervasively with the server being launched as asystemd --userunit (and for the GUI part, I use GNOME which runs the entire thing undersystemd --user), so it works out in the end.If I used true tty sessions that are not linked to
systemd --user, I’d write some small script to backfill the environment from systemd to the tty session and stuck it into the shell profile script (with appropriate safeguards to avoid recursion).TL;DR: it’s much harder than it should be, and unfortunately, the article does not seem to provide an actual true answer.
This is the part where your neighborhood Nushell zealot mentions how nice editing its path config is. The out-of-the box config comes with a tidy list of piped
prependcommands ending in auniqcommand to remove accidental duplicates.this was almost me 🤐 either that or i could mention how windows is a simple global list that applies to all processes/shells/terminals/whatever!
Directions I can provide. Wish I could point to “the right one”. Empirically
~/.profilehas worked for me lately across distros (Debian/Wayland/Plasma, Ubuntu/Wayland/Plasma, Ubuntu/X11/GNOME; edit: openSUSE/Wayland/Plasma) but I have blind spots (been a while since I tried XFCE. Also, I wonder how hard Nix users are laughing).“Amending PATH for GUI sessions” is one of these rabbit holes that takes you through 10-year-old distro reports, DE-specific instructions, display-server-specific startup scripts; I like how my notes on the topic end with an inquisite “PAM?” with no further comments; Past Me may not have survived that last encounter.
I don’t think fd.o covers this? But I might have missed something.
That’s interpreting the prompt as “Amending PATH for the whole graphical session”; interpreting it as “Amending PATH for specific IDE/GUI programs”, … oof.
exec-path, I dimly remember some IDEs automatically sourcing shell dotfiles (or just spawning shells) to ensure tools work according to user expectations?Execclause; so long as you start your program via your desktop launcher, they would have the amended PATH?I’ve always used
echo $0to figure out the shell I’m currently in. But I’ve only ever used unixsh-like shells, so I’m not sure if that works in fish and others.I didn’t know about both methods and used
chshnaively.. Thanks for the lesson :-)