(10.10) not recognizing /usr/local/bin before /usr/bin

[jweaver60]

Homebrew is not recognizing my path. Running brew doctor reveals:

Warning: Homebrew's bin was not found in your PATH.
Consider setting the PATH for example like so
    echo export PATH='/usr/local/bin:$PATH' >> ~/.bash_profile

My path is set as:

/Users/user/.rvm/gems/ruby-2.1.2@main/bin:/Users/user/.rvm/gems/ruby-2.1.2@global/bin:/Users/user/.rvm/rubies/ruby-2.1.2/bin:/usr/local/bin:usr/local/sbin:/usr/local/heroku/bin:/usr/local/share/npm/bin:/Applications/Sublime Text.app/Contents/SharedSupport/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/user/.rvm/bin

[adamv]

Note that you have a path without a leading /: usr/local/sbin

Can you confirm your brew --config?

[jweaver60]

@adamv fixed the path, issue still persists.

HOMEBREW_VERSION: 0.9.5
ORIGIN: https://github.com/Homebrew/homebrew
HEAD: 7bf8a8cdd46a79832b403ce29372f4a6e6386e6c
HOMEBREW_PREFIX: /usr/local
HOMEBREW_CELLAR: /usr/local/Cellar
CPU: 8-core 64-bit sandybridge
OS X: 10.10-x86_64
Xcode: 6.0 => /Applications/Xcode6-Beta.app/Contents/Developer
CLT: 5.1.0.0.1.1396320587
couldn't understand kern.osversion `14.0.0'
GCC-4.2: build 5666
Clang: 6.0 build 600
X11: N/A
System Ruby: 2.0.0-451
Perl: /usr/bin/perl
Python: /usr/bin/python
Ruby: /usr/bin/ruby

[mistydemeo]

Just to sanity-check, is your PATH exported?

[jweaver60]

@mistydemeo yes it is.

[adamv]

Looking at how the doctor checks work, I want to rewrite them to be work more like the audit checks.

[jweaver60]

I'm still having issues, even after reinstall with command line tools.

[adamv]

The doctor checks for PATH share some $ variables. I don't know enough about Ruby versions to know if that's causing a problem here (or if the methods are now being called in a different order perhaps.)

[koenpunt]

It looks like that Ruby is executed in a new shell or something, but without the PATH set..

[koenpunt]

To keep the discussion centralized I'll respond to @adamv here:

We don't check /etc/paths, we only check wharever $PATH ends up being set to.

Yeah sure, but OSX's path_helper (man path_helper) takes care of that. And even when I add and export the PATH to ~/.profile or ~/.bash_profile it still doesn't work..

[koenpunt]

I actually also have problems with git due to the PATH not being set properly. This is unrelated to Homebrew of course, but could maybe help in tackling this problem.

$ git pull
/Applications/Xcode.app/Contents/Developer/usr/libexec/git-core/git-pull: line 11: git-sh-setup: No such file or directory

[jweaver60]

@koenpunt I'm having the same git issue as well.

[adamv]

Someone on 10.10 should edit the doctor check to print out ENV["PATH"]. (And post the results here, just for fun.)

[jarinudom]

@adamv here's what it prints:

/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/Library/Contributions/cmd

I've got /usr/local/bin and /usr/local/bin in .profile, .bashrc, .bash_profile, and .bash_login, along with echo statements in each one so I can see what's being loaded, and none of those files are being loaded when sh runs.

[jarinudom]

Another thing: running brew sh seems to fix everything temporarily (for the current session). Digging through now to see if I can find where it's fixing things.

[koenpunt]

ENV.activate_extensions! seems to set the correct environment variables: https://github.com/Homebrew/homebrew/blob/master/Library/Homebrew/cmd/sh.rb#L6

[jweaver60]

Running brew sh fixed the path warning, but now warns about config scripts in my path.

"config" scripts exist outside your system or Homebrew directories.
`./configure` scripts often look for *-config scripts to determine if
software packages are installed, and what additional flags to use when
compiling and linking.

Having additional scripts in your path can confuse software installed via
Homebrew if the config script overrides a system or Homebrew provided
script of the same name. We found the following "config" scripts:

    /usr/local/Library/ENV/4.3/apr-1-config
    /usr/local/opt/icu4c/bin/icu-config
    /usr/local/opt/libxml2/bin/xml2-config
    /usr/local/opt/libxslt/bin/xslt-config
    /usr/local/opt/ossp-uuid/bin/uuid-config

My path after running brew sh:

/usr/local/bin:/usr/local/sbin:/Users/user/.rvm/bin:/usr/local/heroku/bin:/usr/local/share/npm/bin:/Applications/Sublime Text.app/Contents/SharedSupport/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/Library/ENV/4.3:/usr/local/bin:/usr/local/opt/gettext/bin:/usr/local/opt/icu4c/bin:/usr/local/opt/libxml2/bin:/usr/local/opt/libxslt/bin:/usr/local/opt/openssl/bin:/usr/local/opt/ossp-uuid/bin:/usr/local/opt/sqlite/bin:/Users/user/.rvm/bin

[jarinudom]

@koenpunt I believe it is actually set in Library/Homebrew/cmd/sh.rb:

if superenv?
  # superenv stopped adding brew's bin but generally user's will want it
  ENV['PATH'] = ENV['PATH'].split(File::PATH_SEPARATOR).insert(1, "#{HOMEBREW_PREFIX}/bin").join(File::PATH_S>
end

[koenpunt]

pretty sure it's done std.rb because I commented everything out except for ENV.activate_extensions!

[keith]

@koenpunt This fixes the Git issue https://stackoverflow.com/questions/24022582/osx-10-10-yosemite-beta-on-git-pull-git-sh-setup-no-such-file-or-directory/24023702#24023702

[jarinudom]

@koenpunt ENV.activate_extensions! should be calling extend(Superenv) (loading super.rb) on Yosemite. At least it is for me, maybe there's some difference between our machines that I don't know about. Anyway, I'm starting a branch over here to try to take care of these issues one at a time :)

https://github.com/jarinudom/homebrew/tree/yosemite

[jacknagel]

Looking at the build environment setup isn't going to solve this problem, unfortunately.

Can someone having this issue please point me at their (up to date) dotfiles?

[dsexton]

Without invoking sh as a login shell seems to ignore any dotfile I have tried, but when you add sh -l it does.

[mistydemeo]

Is everyone encountering this problem using iTerm2?

[jweaver60]

I'm using iTerm2.

Edit: So apparently I'm only getting this in iTerm2 and not the default Terminal.

[jarinudom]

Ok here's a workaround. Put the following in ~/.profile

export ENV=/etc/profile

Then open a new terminal and everything should work. Not sure why sh isn't reading /etc/profile anymore (it is supposed to, even in non-interactive mode), but that seems to be the problem.

Source: http://www.gnu.org/software/bash/manual/html_node/Bash-Startup-Files.html

[jweaver60]

@jarinudom This did not work for me, still the same issue.

[dsexton]

Same

[jarinudom]

Never mind, it stopped working after maybe the 3rd or 4th time restarting iTerm2. During that time, I ran launchctl unsetenv PATH (because I had set the PATH via launchctl before) and it worked fine after restarting iTerm2, but then I unloaded and reloaded a launchctl which maybe made it reload its environment?

[DomT4]

Strangely, I haven't had any of the problems discussed in this thread despite using iTerm2 since day one of 10.10 DP1. I did do a clean install of 10.10 DP1, so perhaps that's why I didn't have the issue. Did everyone else here update straight on top of Mavericks?

[gnachman]

If you are having this problem, please try this build of iTerm2:
http://iterm2.com/adhocbuilds/iTerm2-1_0_0_20140617_224912-adhoc.zip

It sets the environment up in a slightly different way, although I doubt that will fix the bug. It also logs a bunch of stuff to Console.app. If you can reproduce the bug with this build, please post the log lines that look like:

Environment var 1: x=y
Environment var 2: x=y
... many more ...
argpath=something

[pilif]

@gnachman your build fixes the issue for me

left is currently released iTerm, right is your special build.

[pilif]

and here's the entries in console.app. Looking good too:

Thank you very much. Finally I can go back to iTerm also when doing stuff that runs subshells (read: basically everything)

[tcarlsen]

@gnachman thank you, thank you, THANK YOU!!!

no more running zsh though bash! this build is fixing this problem for me!

› brew doctor
Your system is ready to brew.

[jweaver60]

@gnachman This fixed it for me as well.

[jarinudom]

@DomT4 I did an upgrade rather than a clean install

[keith]

That works for me!

[gnachman]

If the link I posted above works for you, can you confirm that the nightly build (http://iterm2.com/nightly/latest) is broken? I want to be sure the fix is really what I think it is. The nightly build is substantially different than the betas, so I'm concerned that some other difference between beta and nightly was responsible for the fix.

[jweaver60]

@gnachman The nightly build is indeed broken for me.

[keith]

@gnachman the nightly is also broken for me.

[DomT4]

I'm on Build 1.0.0.20140617-nightly. Haven't been having this issue though. I tried to reproduce the issue but just can't, which has left me rather puzzled. Hopefully this fix works for everyone else though and can be pushed to iTerm2 to fold into the next nightly.

[mseri]

Seems to be fixed in the DP2. Anyhow, I did solve the double PATH entry in the env just by modifying my .bash_profile and .zprofile as follows:

unset PATH
eval `/usr/libexec/path_helper -s`

[jacknagel]

Presumably those with (legal) access to the 10.10 beta also have access to Apple's bug reporting facilities, no? Isn't the whole idea of the beta to find and fix bugs? Has anyone tried filing a bug report with Apple?

In the meantime, I'm leaning towards closing this since it is not something that Homebrew can address.

[mseri]

Yes. I have already reported it. I just wanted to give an easy temporary solution to the people that need it.

[keith]

This should definitely be closed. It is not a homebrew issue.

[DomT4]

I think it's already been submitted as a bug report to Apple by several people. I can always do it again for volume, but I'd presume Apple are at least aware of the situation at this point.

No issues with this being closed though.

[idoo]

same shit in 10.10 final :(

[pilif]

@idoo this is a bug in iTerm. Please update and your issues will go away.

[idoo]

@pilif i have Build 2.9.20141027-nightly
but have this error :(

[tcarlsen]

Im on Build 2.0.0.20141022 and have no promlem at all anymore

[idoo]

but i think v 2.9.20141027-nightly is better (later)

[MikeMcQuaid]

I recommend not running nightly builds and reporting this to iTerm.