2

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.

  • Tried running sh -x as the custom command? Which distro is this? What does gnome-terminal-server's PATH containd? – muru Apr 30 '16 at 11:29
  • Hi @muru, Sorry for the delayed response. 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. I'm on Fedora 23. According to procfs, the parent gnome-terminal-server is PATH is PATH=/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin. I'll update the question to include these information. – Naitree Apr 30 '16 at 14:58
  • What about xterm, or xfce4-terminal? – muru Apr 30 '16 at 15:52
  • @muru, I'm not sure what information you are asking. (I still have much to learn.) But in sh -x custom command environment, echo $TERM outputs xterm-256color. – Naitree Apr 30 '16 at 15:57
  • Well, I'm asking if you see this behaviour in another terminal emulator than GNOME Terminal, like xterm, or xfce4-terminal (or konsole, or terminator, or…). If you see this behaviour in them, we could eliminate GNOME Terminal as the source (and confirm it if none of those show this behaviour). – muru Apr 30 '16 at 15:59
1

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.

  • I do not think this is the case, as ~/.bash_profile does not get sourced at all when bash is not a login shell, nor does it get sourced in sh-compatible mode. However in both situations, ~/.local/bin and ~/bin are present in PATH. – Naitree Apr 30 '16 at 15:18
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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.