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
  • 2
    What does this command return: grep PATH= .profile .bash* ? May 14, 2012 at 15:13
  • .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/SharedSupport/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
    – user49204
    May 14, 2012 at 15:34
  • @user49204 - show that info by editing the question - and when saved check that the formatting makes it understandable
    – mmmmmm
    May 14, 2012 at 17:49

4 Answers 4


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


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


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


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.

  • 1
    Thanks tons. It is interesting to see that my Bash terminal process was launched with a plain 'PATH=/usr/bin:/bin' path. My '/bin/launchctl getenv PATH' returns nothing on Yosemite.
    – Dave X
    Mar 31, 2015 at 21:04
  • What that means is that your path is being set by login(1). "The sequence of directories, separated by colons, searched by csh(1), sh(1), system(3), execvp(3), etc, when looking for an executable file. PATH is set to ``/usr/bin:/bin'' initially by login(1)."
    – chiggsy
    May 21, 2015 at 9:26

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.

  • Thanks but it didn't seems to solve the problem. I don't see that problem in a terminal but only when 3rd party apps tries to invoke access executables under /bin or /usr/bin.
    – user49204
    May 14, 2012 at 15:44
  • Can you give me an example of the third party trying to access these binaries?
    – Aaron Lake
    May 14, 2012 at 15:47
  • Yes, iTerm2 fails to run bash but only /bin/bash. You don't see that behavior when running bash from terminal.
    – user49204
    May 14, 2012 at 15:49
  • 1
    Both of OP’s problematic paths are in his (her?) .bashrc already (see the grep listing in the comment above).
    – kopischke
    May 14, 2012 at 16:28

do you have a .bash_profile? in mine

$ cat bash_profile 

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

$ echo $PATH

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .