Maybe `~/.profile` is where PATH modifications should go

[brson]

@Diggsey had multirust-rs installing path modifications to ~/.profile and I changed it because ~/.profile is only read for login shells, and that seemed wrong since most shells are not login shells. I'm happy to change this to do the right thing, but I'd like to understand better why it's ok not to set the PATH for non-login shells.

Source.

[brson]

As @Diggsey pointed out on IRC the main problem with ~/.profile is that it requires you to actually re-login to take effect, like from your desktop environment, not just start a new shell. This is a major pain in practice.

[matklad]

but I'd like to understand better why it's ok not to set the PATH for non-login shells.

For example if a user launches application (IDE or Emacs, for example) via desktop environment and not via command line, then the PATH will be wrong.

Please note that not all desktop managers execute ~/.profile on startup. I think it is more like ~/.profile ^ ~/.xprofile get executed. I can not point to authoritative documentation on this issue, but this thread in nixos has some info NixOS/nixpkgs#5200 (comment)

[brson]

For example if a user launches application (IDE or Emacs, for example) via desktop environment and not via command line, then the PATH will be wrong.

Ah, ok, that makes a lot of sense. So it's not just cli shells then that run ~/.profile, it's whichever program does the login.

So today if you do any development not under a shell the PATH is going to be misconfigured.

Putting this into ~/.profile again will make it so that you can't just start a new shell after install, but maybe that's ok. We already have instructions after install that say how to source the correct env.

[matklad]

Putting this into ~/.profile again will make it so that you can't just start a new shell after install, but maybe that's ok.

I think I've miscommunicated the part about ~/.xprofile. Depending on your login program, either .profile OR .xprofile will be executed. So putting this just in .profile will not work for some users.

I believe there is no single place where you can robustly do PATH manipulation. And of course there are users who have something like

export PATH="/bin:/usr/bin:/home/matklad_several_years_ago/bin"

in one of their dot files, which undoes all PATH manipulation.

PATH is a global mutable static, so accessing it is unsafe :(

[Diggsey]

The nature of environment variables on linux means we can't hope to get this to "just work" in all cases: .profile will cover the majority of cases, and the remainder will have to be handled by the user. We can only assist them by telling them which directory needs to be added to the PATH.

[nodakai]

I think it is the best practice to have . ~/.profile inside ~/.xprofile assuming either one of them gets executed upon starting a console/GUI session.

[jrobeson]

I doubt ~/.xprofile will be read when running under a Wayland compositor or the Mir equivalent either.

[jrobeson]

In any case, please don't write useless files to my $HOME without asking. I don't have or use ~/.profile (or ~/.xprofile)

[jrobeson]

oh, there's already an issue for that #170

[nodakai]

@jrobeson FYI, X, Wayland and Mir are display servers while it is a display manager like GDM or LightDM which typically sources .xprofile for you and then launches a window manager like fluxbox, Ubuntu Unity or GNOME shell's Mutter. I just found a nice memo on which software shipped by which Linux distro is responsible for sourcing .xprofile:

• https://gist.github.com/marbu/a09ed26c77704441eba3

[jrobeson]

i had no idea about xprofile, because I've never had any ~/.xprofile on any of my linux desktops for at least the past 8 years. I definitely don't want mulitrust to create this file that isn't at all used or required for anything else.