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

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?

  • 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.... Aug 17, 2011 at 19:43
  • 1
    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, 2011 at 19:50

11 Answers 11


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.

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 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:


*To save and quit type a colon (:), then type wq (to write and quit at the same time), followed by Enter.

You can also open the /etc/paths file in a graphical text editor and edit it that way.

Credit to fengd over at Stack Overflow for his answer over there.

  • For vi dimwits (like me) use d to cut a line and p to paste it when in command mode
    – Gerard
    Apr 26, 2014 at 2:02
  • 15
    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, 2014 at 22:39
  • 1
    Is there some point when you stop to consider there is something terribly wrong that a simple install from a package manager designed for OSX is failing out-of-the-box? Changing up your path is a potentially breaking "fix" and BTW, the reason I stumbled on this proposed fix is that brew fails to update my path, also, but "paths" is already in the correct order. Another dead-end. Stop the madness, fix the root cause. Mar 5, 2017 at 20:13
  • 1
    Also, there’s path_helper and /etc/paths.d. Jun 24, 2018 at 10:14

This answer is obsolete. The preferred Homebrew PATH ordering used to be as explained, but that is no longer true. However, the approach is more generally applicable, so for interest’s sake, I’m leaving it up.

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:

[[ :$PATH: == *:$HOME/bin:* ]] || PATH=$HOME/bin:$PATH

This checks whether PATH contains ~/bin, and if not, prepends it. 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/ 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.

  • 1
    Excellent, this answers exactly what I was wondering!
    – N_A
    Aug 5, 2013 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, 2014 at 13:50
  • Not enough detail to help you, sorry. May 16, 2014 at 5:24
  • 1
    @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 Aug 29, 2014 at 16:05
  • 1
    true that, on el cap, I failed with the obsolete answer and succeeded with (I use ZSH) editing the path's order in .zshrc export PATH="/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin"
    – Urs
    Mar 21, 2016 at 17:24

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, e.g., ruby, and break if they get the newer Homebrew version.

From Discrepancy between wiki & brew doctor #10738.  Note that this document goes on to say, "The FAQ (the above quote) refers to the PATH setting for GUI apps; the doctor (the advice to put /usr/local/bin ahead of /usr/bin in your PATH) refers to the PATH setting for CLI apps."

  • 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, 2011 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, 2011 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, 2011 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,
    – mmmmmm
    Aug 18, 2011 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?). Aug 18, 2011 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:

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

  • In OS X, the .bashrc isn't loaded by default. Do you manually source it?
    – slhck
    Apr 18, 2013 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, 2013 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:

  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:


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.


$ /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!

  • 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, 2014 at 22:44

There's a whole slew of good answers here. Here's mine:

echo >> ~/.bashrc alias my="PATH=/usr/local/bin:$PATH"
. ~/.bashrc
my git --version # Brew's fancy git
git --version # Apple's old crusty git

Saves you having to create a separate alias for each program, and as a bonus it leaves the default installations accessible in case you need them.

Works just the same if you're using ZSH; just switch out bashrc for zshrc. You can switch out my for _ or even @ to save on typing.


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'


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"

You can issue the following command in a terminal, it will add the brew home directory + the /bin in the PATH of your whatever SHELL "rc" init file (bash, zsh, csh)

echo "export PATH="'$PATH:$(brew --prefix)/bin' >> ~/.$(basename $SHELL)rc

Enjoy !



I received the error "command not found" when executing a Homebrew command. However, I checked that I had /usr/local/bin in my path as per the other answers in this thread and indeed it was there. ?!?!?!?

An ls -al /usr/local/bin verified all my Homebrew stuff was living in this path. Then it occurred to me: was the command failing mtr living here too?

ls -al /usr/local/bin|grep mtr

Returned no results. Indeed the package mtr puking the error DIDN'T live in the default path. That certainly explains the "command not found" error.


Although everybody and the Homebrew documentation tell you to add /usr/local/bin to your path, there's one other thingy you need to add to your path:


mtr and certain other Homebrew packages require execution via sudo and will live in sbin as opposed to bin.

Adding this path to:


will persistently add it to your paths and now when you execute one of these commands, it will work as intended-


for Apple Silicon


open your bash profile

vi ~/.bash_profile

add the following to your profile

export PATH="/opt/homebrew/bin:$PATH"

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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