Re: How To Permanently Add-to a Users PATH Statement in the Bash Shell
On Wed, Jul 08, 2020 at 07:53:53AM -0500, Nate Bargmann wrote:
> https://noah.meyerhans.us/2020/07/07/setting-environment-variables-for-gnome-session/
> As I read it, where an environment variable should be set depends on the
> intended scope of the variable. One comment in response to the blog
> post states that ~/.profile should be used to set such variables and
> that even Gnome on Wayland will read this file (I've not tried it yet
> myself).
I've heard this also, but I have no evidence for or against it. If it's
true, it's *unique* to the Wayland session, because that sure as hell is
false for X11 sessions.
> There is a caveat! Isn't there always? The comments at the top of
> /etc/skel/.profile note:
>
> # ~/.profile: executed by the command interpreter for login shells.
> # This file is not read by bash(1), if ~/.bash_profile or ~/.bash_login
> # exists.
You're over-thinking this.
> For whatever historical reason I do have ~/.bash_profile which does
> nothing other than source ~/.bashrc when Bash is invoked as a login
> shell. I think I'll move it out of the way and use ~/.profile instead.
Set aside all of the X11 and Wayland and display manager and X session
stuff, and look ONLY at the shell.
When bash is invoked as a login shell (e.g. when you log in via ssh, or
on the console), it reads one of the following files:
~/.bash_profile
~/.bash_login
~/.profile
It searches for them in that order, and the first one that it finds is
what it reads. Let's call this file "the profile".
YOU, the end user, are expected to configure "the profile" so that it
dots in (or sources, if you're sure you're in bash) the ~/.bashrc file
so that you also get your aliases, functions, and so forth, in your
login shell.
So, in a standard console-only setup, we might have the following files:
=== ~/.profile ===
export PATH=$HOME/bin:$PATH:/sbin:/usr/sbin
export EDITOR=vim
export VISUAL=vim
test "$BASH_VERSION" && . ~/.bashrc
======
=== ~/.bashrc ===
set -o vi
set +o histexpand
alias ll='ls -l'
======
Note that the standard Debian profile (/etc/skel/.profile) uses a similar
test to dot in ~/.bashrc and prepend ~/bin to PATH, so if you're using
the standard profile, it's pretty similar to what I wrote here.
The reason there's more than one possible filename for the profile is
largely historical, but it also ties into the fact that your home
directory can be *shared* across multiple systems. And you might have
different login shells on different systems. (Or, you might be the
kind of person who switches your login shell from time to time, and you
want to make sure you can still login with a mostly-sane environment
regardless of which shell is currently selected.)
The ~/.profile file is the traditional profile used by the Bourne shell,
the POSIX shell, and the Korn shell. Bash reads it for compatibility.
However, bash has a lot of extensions that these other shells may not
offer, so you aren't supposed to put bash-specific syntax into ~/.profile,
because some day, it might be read by a different login shell.
With that in mind, bash offers the alternatives ~/.bash_profile and
~/.bash_login (the latter with csh refugees in mind). Bash is the only
shell that will read either of those files, so if you use one of those,
you're safe to put bash syntax in it.
In a multi-shell environment (NFS shared home, or frequent use of chsh),
you might choose to put most of your environment variable in ~/.profile,
where they will be read by every file. Then, you might choose to have
~/.bash_profile dot in ~/.profile, and then perform a bunch of
bash-specific tasks, and then finally dot in ~/.bashrc.
Or, you might choose to retain only ~/.profile and keep it shell-neutral.
There are lots of choices here. And this is with only the login shell
layer involved -- no X11 or Wayland.
> Okay, having tried that I see that it works! Set a variable in
> ~/.profile, restart the Gnome session (I did a warm restart and cold
> boot) and using the "Run Command" dialog (Alt-F2 in Gnome) run:
>
> 'sh -c "env > /tmp/env"
>
> and then see if your custom variable is set. In my case with the laptop
> running Bullseye it does work. I now see several things that I dumped
> in ~/.bashrc that aren't Bash specific and would be better put in
> ~/.profile. Good thread.
That's interesting, but I'm not sure I fully trust that test you
performed. I don't know whether the "Run Command dialog" is doing
something secretly. I'd prefer to check the actual starting environment
of one of the GNOME processes. I don't know what their names are, but
assuming you can find one that looks like it was started at the time
you logged in, grab its PID and then do something like this:
tr \\0 \\n < /proc/its_pid_here/environ | grep your_variable_here
That will show you the initial environment of that process, without
letting "Run Command" get involved to do any tricky stuff.
If it turns out that the Wayland session really does dot in ~/.profile,
that's yet another reason why you need to ensure that it remains
shell-neutral. I would imagine that Wayland dots it in from a POSIX
shell (the same way the Debian X11 session dots in ~/.xsessionrc from
a POSIX shell).
Reply to: