Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Trying to set up Homebrew on a new Mac (on previous Macs I would install packages from source).

The first package I tried to install was Git:

$ brew install git

Installation went OK, but which git still shows the one in /usr/bin/git that came along with Lion (I think?). And not the one in /usr/local/bin/git that was just installed.

$ echo $PATH
/Users/meltemi/.rvm/gems/ruby-1.9.2-p290@rails31/bin:/Users/meltemi/.rvm/gems/ruby-1.9.2-p290@global/bin:/Users/meltemi/.rvm/rubies/ruby-1.9.2-p290/bin:/Users/michael/.rvm/bin:/usr/local/mysql/bin:/opt/subversion/bin:/Developer/Additions/checker/:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin

As you can see /usr/bin defaults to before /usr/local/bin in the $PATH

So, I'm confused! I thought the point of HomeBrew (and something the creators seem to brag about) was that you don't have to mess with the $PATH variable!?!

So, what did I do wrong?

share|improve this question

migrated from stackoverflow.com Aug 18 '11 at 1:16

This question came from our site for professional and enthusiast programmers.

    
did you mess with your path previously and maybe put them in the wrong order? Also Im not sure why this is a "bragging point" form homebrew... it not like the concept of a path or modifying it is a complex thing which involves authoring and sprinkling 10 different plists across your system with special permissions or something.... –  prodigitalson Aug 17 '11 at 19:43
    
path, well the part that isn't RVM related, should be standard issue. And no, I'm not complaining about having to change the path. It's just that they seem to repeat the claim If you choose /usr/local, everything 'just works!' that I have to wonder what I'm missing...because it doesn't "just work". –  Meltemi Aug 17 '11 at 19:50

7 Answers 7

up vote 40 down vote accepted

I found this related post to be very helpful. Instead of changing the $PATH variable, it just has you simply edit your /etc/paths file.

http://stackoverflow.com/questions/10343834/homebrew-wants-me-to-amend-my-path-no-clue-how

As soon as I followed the directions and put /usr/local/bin above /usr/bin, my issues were resolved.

  1. On OS X, open Terminal
  2. Type the command: sudo vi /etc/paths
  3. Enter your password if you're asked for it
  4. You will see a list of paths. Edit the list them so that /usr/local/bin path is entered above the /usr/bin path
  5. *Save and quit
  6. Restart Terminal

Here's what mine looks like after I did that:

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

*To save and quit type a colon (:), then type wq (to write and quit at the same time.) You can also open the /etc/path file in a text editor and edit it that way.

Credit to @jrwren over at StackOverflow for his answer over there.

share|improve this answer
    
For vi dimwits (like me) use d to cut a line and p to paste it when in command mode –  Gerard Apr 26 at 2:02
1  
I would use caution with this -- the better answer is to just amend the path in .profile / .bash_profile and export it there. By changing /etc/paths, you (potentially) affect all system processes; changing PATH in .profile / .bash_profile localizes the preference to both your account and those commands invoked via the command shell (which, in my case for development, is what I want). If you're really cautious, you can do what @Aristotle Pagaltzis suggests in the answer below. –  rholmes May 16 at 22:39

You haven't done anything wrong, but it does seem pretty clear that if you had /usr/local/bin in your path before /usr/bin this specific problem would go away. The easiest fix is to do just that and put something like

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

in your ~/.bash_profile so everything that Homebrew installs is found first. That's the way that I have it set up on my Mac, and it has worked for me for this long, however, YMMV.

It does appear that they believe it would work with /usr/local/bin being after /usr/bin, so while I might have mucked up my own $PATH, I can see where their documentation lacks:

Note that you should put /usr/local/bin after /usr/bin because some programs will expect to get the system version of eg. ruby, and break if they get the newer Homebrew version.

From the section on My GUI .apps don’t find /usr/local/bin utilities!

share|improve this answer
1  
Won't this leave two /usr/local/bins in my $PATH? I believe so. I wonder if we should instead be editing the order of the default paths in /etc/paths or the contents of /etc/paths.d? But this will affect every user...maybe not a bad thing. Anyway, just wanted to see how other people have approached this. –  Meltemi Aug 17 '11 at 19:58
    
@Meltemi, the spirit of this answer is correct: update your PATH (in the manner of your choosing) to have /usr/local/bin precede /usr/bin. I personally update my PATH in .bash_profile as suggested here. –  shelhamer Aug 17 '11 at 20:21
    
@Nick- interesting information...and only serves to confuse matters (at least my matters)...Homebrew docs seem to imply that Terminal commands should pick up apps in /usr/local/bin even though it trails /usr/bin in the path. But GUI apps need special coddling? IT would seem all apps, GUI or not, need us to adjust the $PATH variable. So, what am I (or the Homebrew creators) missing? –  Meltemi Aug 18 '11 at 0:44
    
I think Homebrew assumes you want to use the Apple supplied executable first - git is a change as until Lion it was not supplied by Apple thus Homebrew needed it - now you can use the Apple one, –  Mark Aug 18 '11 at 12:27
    
I agree with Mark on this. With MacPorts and Fink, the assumption was to provide a completely pristine, separate environment from anything Apple supplied out of the box. Homebrew took the stance that Apple's stuff is great and not to avoid using it (why download another version of gcc when Apple's will likely do?). –  Nick Klauer Aug 18 '11 at 19:13

You shouldn’t.

Homebrew intentionally keeps /usr/local/bin after /usr/bin in the path for maximum compatibility. Reversing the order of these directories in PATH by editing /etc/paths would mean that all programs anywhere on the system, no matter how they were started, will get the Homebrew version of a command. But some may specifically expect Apple’s version, or just not be able to use a newer version, etc.

How to preserve this principle and still get the Homebrew-installed version of git? As the saying goes, all problems can be solved with a layer of indirection (except having too many layers of indirection). — Or in this case, as it turns out, two layers.

Specifically, it’s been part of my Unix habits to have a ~/bin directory which I put at the start of my PATH. This is one of the first bits in my .bashrc:

case ":$PATH:" in
  *:$HOME/bin:*) ;;     # do nothing if $PATH already contains $HOME/bin
  *) PATH=$HOME/bin:$PATH ;;  # in every other case, add it to the front
esac

With that in place, then selectively making just the Homebrew-managed git take precedence over the system version (instead of every Homebrew-managed binary), and just for your shell sessions (instead of all programs started from anywhere, including GUI programs), is as simple as symlinking it:

ln -s /usr/local/bin/git ~/bin/git

You could symlink /usr/local/Cellar/git/1.8.2.1/bin/git directly, but then you would have to fix your symlink every time you did a brew upgrade git (directly or indirectly). By symlinking to Homebrew’s fixed-location symlink, you don’t have to worry about it.

So you add a directory to your $HOME so you can add it your PATH so you can symlink to a symlink, and that fixes your problem and puts a smile on Dr Seuss. Yo dawg I herd you like symlinks so we put a path in your PATH so you can symlink while you symlink.

share|improve this answer
    
Excellent, this answers exactly what I was wondering! –  mydogisbox Aug 5 '13 at 22:26
    
This SEEMS like the right answer, but I can't figure out the exact commands to run. I keep getting "File exists" when creating symlinks. –  Ryan May 15 at 13:50
    
Not enough detail to help you, sorry. –  Aristotle Pagaltzis May 16 at 5:24
    
@Ryan make sure you have the order of args right in the ln command. The first path is the target, and the second is the symlink –  Freedom_Ben 20 hours ago

I disagree with jthomas' answer. Editing your /etc/paths file will change the load paths for all programs. This could be dangerous if a system application is expecting to find a specific version of a binary but finds a different version because you have edited your paths file. Instead, change your path variable in ~/.bashrc (or ~/.bash_profile). Then your load path will only change inside the terminal:

# Add homebrew app to PATH
export PATH=/path/to/homebrew/app/bin:$PATH

Then reload bash or source ~/.bashrc, and you're good to go. Since the homebrew path comes before anything else, bash will load the version that you downloaded with homebrew.

share|improve this answer
    
In OS X, the .bashrc isn't loaded by default. Do you manually source it? –  slhck Apr 18 '13 at 8:50
    
Oh, yeah. I came from OS X from Ubuntu and was used to having a .bashrc so I source it from my .bash_profile. If you don't want to create the rc file, you can add the command to your .bash_profile. –  Nathan Apr 19 '13 at 17:29

Rather than messing with the PATH at all (which in my history comes back to burn me months later) I added an alias for git in my zsh custom aliases directory (~/.zshrc/custom/git_alias.zsh).

alias git='/usr/local/bin/git'

share|improve this answer
    
I wasn't aware of that...thanks! –  Meltemi Jul 30 '13 at 19:53

As I understand it, brew doesn't put anything in /usr/local/bin that collides (has the same name as) an Apple distributed executable. Therefore, having /usr/local/bin in the path before /bin and /usr/bin shouldn't be an issue, because there should be no name collisions. *However, see the issues with ls and tar, and using other package aggregators like fink and port (MacPorts), way below.

Brew does one of two things that I know of that help manage name collisions:

  1. Brew leaves unlinked kegs in the Cellar. To install stuff, brew leaves the tools where they are, and creates symbolic links to those tools in /usr/local/bin. For tools which brew doesn't want a name collision with, it doesn't create a symbolic link.
  2. For many if not all of the standard tools which are also in /bin and /usr/bin, brew prefixes the link in /usr/local/bin with a "g", so for instance, to perform an ls with a brew version, use gls. Simply do an ls -l in /usr/local/bin and look for the linked files - those are the ones brew put there. Note: The brew installed tools that must be accessed by their real names are found in /usr/local/Cellar/coreutils/8.21/libexec/gnubin.

I don't put /usr/local/bin in my path for two reasons - those reasons are at the bottom of my answer.

To assess the name collisions in your system, use brew doctor and look for this section - Here's the brew doctor's output of interest:

Warning: /usr/bin occurs before /usr/local/bin
This means that system-provided programs will be used instead of those
provided by Homebrew. The following tools exist at both paths:

    ctags
    emacs
    emacsclient
    etags
    ex
    git
    git-cvsserver
    git-receive-pack
    git-shell
    git-upload-archive
    git-upload-pack
    rview
    rvim
    view
    vim
    vimdiff
    vimtutor
    xxd

Consider setting your PATH so that /usr/local/bin
occurs before /usr/bin. Here is a one-liner:
    echo export PATH='/usr/local/bin:$PATH' >> ~/.bash_profile

The reason I don't put brew's tools first, in fact, not at all, is because the brew installed ls and tar commands do not handle the filesystem ACL properly, in fact, last time I checked (which was last week), they weren't handled at all. This is a BIG problem, and to avoid it altogether, along with the associated man page configuration issue that tags along with setting the $PATH right, I make sure I put the OSX related tools, especially those found in /bin and /usr/bin, first.

Another reason I don't even put /usr/local/bin in my path at all is because brew doesn't play well with others, and fink and port (MacPorts) have way more supported packages at present that I need NOW. For instance, I can get gnome-terminal with fink, but it would be a big effort to construct a formula and do the same with brew. So, I keep /sw and /opt in my search $PATH (for fink and port, respectively) and reference things I need from /usr/local/bin, including gnat, either spelled out, or I use bash alias's, or I source a setup file for an entirely different environment when I writing Ada code.

The thing is, it really depends on what you want and need at the time.

Here's an example of the ACL problem that I mentioned above.

With the standard OSX tools:

$ /bin/ls -le /var/root | head -7
total 24
drwx------+  3 root  wheel  102 May 28  2013 Desktop
 0: group:everyone deny delete
 1: user:_spotlight inherited allow list,search,readattr,readextattr,readsecurity,file_inherit,directory_inherit
drwx------+  6 root  wheel  204 Sep 19 14:22 Documents
 0: group:everyone deny delete
 1: user:_spotlight inherited allow list,search,readattr,readextattr,readsecurity,file_inherit,directory_inherit

and with the brew installed tools:

$ /usr/local/bin/gls -le /var/root
/usr/local/bin/gls: invalid option -- 'e'
Try '/usr/local/bin/gls --help' for more information.

and

$ /usr/local/bin/gls --help | grep -i acl

You'll get similar results with tar and I don't know home many other brew tools, but who can afford to have something break 6 months down the road because of an ACL problem!

share|improve this answer
    
Thanks for the useful info. As a note, however, on my system right now, I do have executables with the same name in both /usr/bin and /usr/local/bin (e.g., git, which IS symlinked, as you note). So, they do conflict by default. I also do want to override the system tools for my shell work. –  rholmes May 16 at 22:44

I prefer limiting changes to environvent variables like $PATH to users who actually want the change. Thus, I simply add the following to ~/.bashrc:

export PATH="$(brew --prefix)/bin:$PATH"
share|improve this answer

Your Answer

 
discard

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.