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

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

Solution 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.

Solution 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.