Executables in /bin and /usr/bin are not found in path

Question

Somehow I can’t execute files in /bin or /usr/bin without providing the full path.

This isn’t happening when running from Terminal, but, for example, iTerm can’t run bash (only /bin/bash), OnyX can't run sw_vers.

.profile: export PATH=/opt/local/bin:/opt/local/sbin:/bin:/usr/bin:$PATH 
.profile: export PATH=$PATH 
.bash_history: export PATH="$PATH:"'/Users/gilstrauss/Applications/CrossOver.app/Contents/SharedSuppor‌​t/CrossOver/bin' 
.bash_history: export PATH=/opt/local/bin:/opt/local/sbin:$PATH 
.bash_history: export PATH=${PATH}:/bin 
.bash_profile: export PATH=/bin:$PATH 
.bashrc: export PATH=${PATH}:/bin:/usr/bin

Answer 1

Terminal.app correctly starting the shell does’t mean much: it runs /usr/bin/login (with the full path) by default, which invokes your default shell (again: defined with a full path) as an interactive login shell (which will in turn read both .profile and .bashrc and leave you with a working $PATH). Your problem is non-interactive shells, which do neither, do not get any $PATH settings. That seems to point to OS X’ default path settings having somehow been clobbered.

To check this, run cat /etc/paths. The output should (at the very least) be

/usr/bin
/bin
/usr/sbin
/sbin

(these are the defaults on a pristine OS X install). If the first two are missing, you have your cause – and an easy solution:

mv /etc/paths /etc/paths.old # if you want to keep the current contents
def_paths=(/usr/bin /bin /usr/sbin /sbin)
for p in ${def_paths[@]}; do echo $p >> /etc/paths; done
cat /etc/paths.old >> /etc/paths # append previous contents

Note that as /etc/paths is owned by root, you will have to sudo su for this to work.

Answer 2

In OS X it's launchd that sets the initial path for everything, not your terminal files.

Now, on an unrelated note, I just found out that in OS X

ps -E 

will show the environment that the process has been given. I'm sure everybody knew this except for me,but I'm very excited! Why?

Because now I can provide a partial answer.

ps -EA

Will show you the environment that every process started whether said process has a controlling terminal or not. You should see

/usr/bin:/bin:/usr/sbin:/sbin

Which is what you should also get when you type in

/bin/launchctl getenv PATH

since launchd sets the path. It is here where your problem lies, I feel, not in your dotfiles. You might find reading the manpage for environ(7) as well as path_helper(8) useful. When the system is working properly, every app you run should have the same environment given it by launchd. The fact that Onyx is malfunctioning means that it's not shell issue, but rather a system one.

It's very important launchctl/launchd is setting the path correctly.

Answer 3

Not sure how it happened but your PATH went haywire, luckily it's an easy fix. Run the following in Terminal (or iTerm) to fix the issue:

echo "export PATH=$PATH:/bin:/usr/bin" >> ~/.bashrc
source ~/.bashrc

This will add /bin and /usr/bin to the end of your PATH for this and all future terminal sessions.

Answer 4

do you have a .bash_profile? in mine

$ cat bash_profile 

source ~/.bashrc
export PATH=$PATH:/opt/local/bin:/opt/local/sbin

$ echo $PATH
/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/usr/local/git/bin:/usr/local/julia:/usr/local/MacGPG2/bin:/usr/texbin:/opt/local/bin:/opt/local/sbin

(for macports to the path). It stands to reason that you could just have in .bash_profile the line

export PATH=$PATH:/bin:/usr/bin

And see how it goes. My guess is that you must have done something very serious to your machine, so do make a backup of your files, and test for software and also hardware soundness.