Does gnome-terminal modify PATH when invoking shell

Question

I guess gnome-terminal might have modified PATH environ variable when invoking shell. Specifically, $HOME/.local/bin:$HOME/bin will always be appended to PATH.

I did the following experiment to demonstrate this:

• Open a gnome-terminal
• traverse through "Edit" -> "Preference" -> "Profiles" and "Edit" your current profile (which is "Unamed" for me)
• Under the "Command" tab, check "Run a custom command instead of my shell" and fill in the following input area with sh. In this way, bash should be called in sh-way and it's not a login shell.
• To further make sure the /etc/profile, $HOME/.bash_profile, $HOME/.bashrc doesn't get sourced, we rename these files temporarily. (Actually, these files should NOT get sourced already, as we are invoking a non-login sh.)

• Now, open a new gnome-terminal window and run echo $PATH. Here is what I got:

  /usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/home/naitree/.local/bin:/home/naitree/bin
  

I don't understand why the last two path appeared in PATH.

Based on this fact, I think the following possible explanations exists:

1. the PATH is inherited from parent process, which in this case is the gnome-terminal-server.
2. the PATH is modifed in some script that is sourced mysteriously by sh at some point.
3. the PATH is modifed when gnome-terminal-server forks off the subprocess.

Now I think I have ruled out the #1 and the #2 possibilties:

1. cat /proc/$PPID/environ where $PPID is the PID of gnome-terminal-server shows that its PATH variable is /usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin, which does not contain what we are looking for.

2. In the sh we have just opened, run export -n PATH and sh -x, I can see nothing get sourced during the init process of this new sh. And its PATH is clean:

   /usr/local/bin:/usr/bin
   

Which leaves me the last possibility.

Did I missed something? Is gnome-terminal the culprit for the mysteriously modified PATH?

---

Update:

I just tried sh -x as the custom command. Upon opening gonme-terminal, I didn't see anything get sourced. But, echo $PATH says that $HOME/.local/bin and $HOME/bin are there.

Here are distro related info:

• Fedora 23 (4.4.8-300.fc23.x86_64)
• bash version 4.3.42(1)-release (x86_64-redhat-linux-gnu)

---

Update2:

I just tried:

• Add echo "$PATH" at the very beginning of ~/.bashrc.
• opening gnome-terminal with bash in the default non-login shell mode, with custom command bash -x.

Based on debug ouput, I observed that the ~/.bashrc is the starting point of script sourcing. But the $HOME/.local/bin and $HOME/bin are already there in PATH even before that.

Answer 1

I had a similar problem, with the terminal PATH being initially set to /usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin.

Having checked all the usual suspects, ~/.bashrc, ~/.bash_profile, /etc/bashrc, /etc/profile, I resorted to changing the DefaultEnvironment setting in both /etc/systemd/system.conf and /etc/systemd/user.conf. But I still ended up with /usr/local/... in the PATH.

By chance I came across a reference to pam_env whilst trying to figure out where the path environment was being set. So I added the following line to /etc/security/pam_env.conf:

PATH DEFAULT=/bin:/sbin

After logging back in, the terminal shell PATH was then free of the pesky local paths.

I am pretty sure the defaults come from pam_env, as after changing the systemd configuration, neither PID 1 nor the systemd --user process has the local paths in the environment, but gnome-terminal-server did.

Modern Linux is becoming a configuration nightmare.

I realise this is not an answer to the OP's issue. But it seemed sufficiently related to be worth a mention.

Answer 2

According to a comment on Fedora, Adding ~/.local/bin to default PATH, this was a Fedora-specific change in the bash configuration, a few years ago.

The change was made in the RPM (not upstream), and undocumented.