Take the 2-minute tour ×
Ask Different is a question and answer site for power users of Apple hardware and software. It's 100% free, no registration required.

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
share|improve this question
What does this command return: grep PATH= .profile .bash* ? –  glenn jackman May 14 '12 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/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 –  user49204 May 14 '12 at 15:34
@user49204 - show that info by editing the question - and when saved check that the formatting makes it understandable –  Mark May 14 '12 at 17:49
add comment

4 Answers

up vote 3 down vote accepted

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.

share|improve this answer
add comment

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.

share|improve this answer
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 '12 at 15:44
Can you give me an example of the third party trying to access these binaries? –  Aaron Lake May 14 '12 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 '12 at 15:49
Both of OP’s problematic paths are in his (her?) .bashrc already (see the grep listing in the comment above). –  kopischke May 14 '12 at 16:28
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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