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....
–
prodigitalsonAug 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".
–
MeltemiAug 17 '11 at 19:50

For vi dimwits (like me) use d to cut a line and p to paste it when in command mode
–
GerardApr 26 '14 at 2:02

3

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.
–
rholmesMay 16 '14 at 22:39

Homebrew intentionally keeps /usr/local/binafter/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.

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.

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.
–
MeltemiAug 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.
–
shelhamerAug 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?
–
MeltemiAug 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,
–
MarkAug 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 KlauerAug 18 '11 at 19:13

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:

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.
–
NathanApr 19 '13 at 17:29

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:

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.

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:

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 bashalias'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.

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.
–
rholmesMay 16 '14 at 22:44