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.
Yo dawg I herd you like symlinks so we put a path in your PATH so you can symlink while you symlink. 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. By symlinking to Homebrew’s fixed-location symlink, you don’t have to worry about it.
#OSX BREW UPGRADE#
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). 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 This checks whether PATH contains ~/bin, and if not, prepends it. Specifically, it’s been part of my Unix habits to have a ~/bin directory which I put at the start of my PATH. Or in this case, as it turns out, two layers.
#OSX BREW HOW TO#
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). But some may specifically expect Apple’s version, or just not be able to use a newer version, etc. 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. Homebrew intentionally keeps /usr/local/bin after /usr/bin in the path for maximum compatibility. However, the approach is more generally applicable, so for interest’s sake, I’m leaving it up. The preferred Homebrew PATH ordering used to be as explained, but that is no longer true.
0 kommentar(er)
