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:
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!
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 – 2011-08-17T19:43:51.487
1path, 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 – 2011-08-17T19:50:42.670