Ich fand diesen verwandten Beitrag sehr hilfreich. Anstatt die Variable $PATH zu ändern, lässt er Sie einfach Ihre /etc/paths-Datei bearbeiten. Homebrew will, dass ich meinen PATH ändere; keine Ahnung wie

Sobald ich den Anweisungen folgte und /usr/local/bin über /usr/bin setzte, waren meine Probleme gelöst.

1. Unter OS X öffnen Sie Terminal
2. Geben Sie den Befehl ein: sudo vi /etc/paths
3. Geben Sie Ihr Passwort ein, wenn Sie danach gefragt werden
4. Es wird eine Liste von Pfaden angezeigt. Bearbeiten Sie diese so, dass der Pfad /usr/local/bin oberhalb des Pfades /usr/bin eingetragen ist
5. *Speichern und Beenden
6. Starten Sie das Terminal neu

So sieht meines aus, nachdem ich das getan habe:

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

*Um zu speichern und zu beenden, tippen Sie einen Doppelpunkt (:), dann geben Sie wq ein (um gleichzeitig zu schreiben und zu beenden), gefolgt von Enter.

Sie können die Datei /etc/paths auch in einem grafischen Texteditor öffnen und sie auf diese Weise bearbeiten.

Dank an fengd drüben bei Stack Overflow für seine Antwort dort.

Diese Antwort ist veraltet. Die bevorzugte Homebrew PATH-Reihenfolge war früher wie erklärt, aber das ist nicht mehr wahr. Der Ansatz ist jedoch allgemeiner anwendbar, also lasse ich ihn interessehalber stehen.

Sie sollten nicht.

Homebrew hält absichtlich /usr/local/bin nach /usr/bin im Pfad für maximale Kompatibilität. Die Umkehrung der Reihenfolge dieser Verzeichnisse in PATH durch Editieren von /etc/paths würde bedeuten, dass alle Programme irgendwo auf dem System, egal wie sie gestartet wurden, die Homebrew-Version eines Befehls erhalten. Aber einige erwarten vielleicht speziell die Version von Apple, oder können einfach keine neuere Version verwenden, usw.

Wie kann man dieses Prinzip bewahren und trotzdem die von Homebrew installierte Version von git erhalten? Wie das Sprichwort sagt, können alle Probleme mit einer Schicht der Indirektion gelöst werden (außer zu viele Schichten der Indirektion zu haben). - Oder in diesem Fall, wie sich herausstellt, mit zwei Schichten.

Genauer gesagt, gehört es zu meinen Unix-Gewohnheiten, ein ~/bin-Verzeichnis zu haben, das ich an den Anfang meines PATH setze. Dies ist eines der ersten Bits in meinem .bashrc:

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

Dies prüft, ob PATH ~/bin enthält, und wenn nicht, wird es vorangestellt. Wenn das erledigt ist, kann man selektiv nur das von Homebrew verwaltete git der Systemversion vorziehen (statt jeder von Homebrew verwalteten Binärdatei), und zwar nur für die Shell-Sitzungen (statt aller Programme, die von irgendwoher gestartet werden, einschließlich GUI-Programmen), indem man es einfach mit einem Symlink verknüpft:

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

Sie könnten /usr/local/Cellar/git/1.8.2.1/bin/git direkt symlinken, aber dann müssten Sie Ihren Symlink jedes Mal korrigieren, wenn Sie ein brew upgrade git machen (direkt oder indirekt). Indem Sie einen Symlink auf Homebrews Symlink mit fester Position setzen, müssen Sie sich darüber keine Gedanken machen.

Sie fügen also ein Verzeichnis zu Ihrem $HOME hinzu, damit Sie es zu einem Symlink hinzufügen können, und das behebt Ihr Problem und zaubert ein Lächeln auf Dr. Seuss. Yo dawg I herd you like symlinks so we put a path in your PATH so you can symlink while you symlink.

Sie haben nichts falsch gemacht, aber es scheint ziemlich klar zu sein, dass dieses spezielle Problem verschwinden würde, wenn Sie /usr/local/bin in Ihrem Pfad vor /usr/bin hätten. Die einfachste Lösung ist, genau das zu tun und etwas wie

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

in Ihr ~/.bash_profile zu setzen, damit alles, was Homebrew installiert, zuerst gefunden wird. Das ist die Art und Weise, wie ich es auf meinem Mac eingerichtet habe, und es hat für mich so lange funktioniert, aber YMMV.

Es scheint, dass sie glauben, es würde mit /usr/local/bin nach /usr/bin funktionieren, also während ich mein eigenes $PATH verpfuscht haben könnte, kann ich sehen, wo ihre Dokumentation fehlt:

Beachten Sie, dass Sie /usr/local/bin nach /usr/bin setzen sollten, da einige Programme erwarten, die Systemversion von z.B. Ruby zu erhalten und abbrechen, wenn sie die neuere Homebrew-Version erhalten.

Aus Discrepancy between wiki & brew doctor #10738 .  Beachten Sie, dass es in diesem Dokument weiter heißt: “Die FAQ (das obige Zitat) bezieht sich auf die PATH-Einstellung für GUI-Anwendungen; der Doktor (der Ratschlag, /usr/local/bin vor /usr/bin in Ihren PATH zu setzen) bezieht sich auf die PATH-Einstellung für CLI-Anwendungen.”

Ich stimme nicht mit der Antwort von jthomas überein. Wenn Sie Ihre Datei /etc/paths bearbeiten, werden die Ladepfade für alle Programme geändert. Das könnte gefährlich sein, wenn eine Systemanwendung erwartet, eine bestimmte Version eines Binärprogramms zu finden, aber eine andere Version findet, weil Sie Ihre Pfade-Datei bearbeitet haben. Ändern Sie stattdessen Ihre Pfadvariable in ~/.bashrc (oder ~/.bash_profile). Dann ändert sich Ihr Ladepfad nur innerhalb des Terminals:

Homebrew-App zu PATH hinzufügen

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

Dann laden Sie die bash neu oder source ~/.bashrc, und Sie sind startklar. Da der Homebrew-Pfad vor allem anderen steht, wird die Bash die Version laden, die Sie mit Homebrew heruntergeladen haben.

So wie ich es verstehe, wird in brew nichts abgelegt, das mit einer von Apple verteilten ausführbaren Datei kollidiert (den gleichen Namen hat). Daher sollte es kein Problem sein, /usr/local/bin im Pfad vor /usr/local/bin und /bin zu haben, da es keine Namenskollisionen geben sollte. *Siehe jedoch die Probleme mit /usr/bin und ls und der Verwendung anderer Paketaggregatoren wie tar und fink (MacPorts), weiter unten.

port macht eine von zwei Sachen, von denen ich weiß, dass sie helfen, Namenskollisionen zu verwalten:

1. Brew lässt unverknüpfte Fässer im Keller. Um Sachen zu installieren, lässt brew die Tools dort, wo sie sind, und erstellt symbolische Links zu diesen Tools in Brew. Für Werkzeuge, mit denen /usr/local/bin keine Namenskollision wünscht, legt es keinen symbolischen Link an.
2. Für viele, wenn nicht alle der Standardwerkzeuge, die auch in brew und /bin enthalten sind, stellt /usr/bin dem Link in brew ein “g” voran. Um also z. B. ein /usr/local/bin mit einer Brau-Version durchzuführen, verwenden Sie ls. Führen Sie einfach ein gls in ls -l aus und suchen Sie nach den verlinkten Dateien - das sind die, die /usr/local/bin dort abgelegt hat. Hinweis: Die von brew installierten Tools, auf die mit ihrem richtigen Namen zugegriffen werden muss, befinden sich in brew.

Ich nehme /usr/local/Cellar/coreutils/8.21/libexec/gnubin aus zwei Gründen nicht in meinen Pfad auf - diese Gründe stehen unten in meiner Antwort.

Um die Namenskollisionen in Ihrem System zu beurteilen, verwenden Sie /usr/local/bin und suchen Sie nach diesem Abschnitt - hier ist die Ausgabe von brew doctor von Interesse:

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

Der Grund, warum ich die Werkzeuge von brew doctor nicht an die erste Stelle setze, eigentlich überhaupt nicht, ist, dass die Befehle brew installiert brew und ls die Dateisystem-ACL nicht richtig behandeln, tatsächlich, als ich das letzte Mal nachgesehen habe (was letzte Woche war), wurden sie überhaupt nicht behandelt. Das ist ein GROSSES Problem, und um es ganz zu vermeiden, zusammen mit dem damit verbundenen Problem der tar-Seitenkonfiguration, das mit der richtigen Einstellung der man einhergeht, stelle ich sicher, dass ich die $PATH-bezogenen Werkzeuge, insbesondere die in OSX und /bin, zuerst einsetze.

Ein weiterer Grund, warum ich /usr/bin überhaupt nicht in meinen Pfad aufnehme, ist, dass /usr/local/bin nicht gut mit anderen zusammenspielt und brew und fink (MacPorts) derzeit viel mehr unterstützte Pakete haben, die ich JETZT brauche. Zum Beispiel kann ich port mit gnome-terminal bekommen, aber es wäre ein großer Aufwand, eine Formel zu konstruieren und das gleiche mit fink zu tun. Also behalte ich brew und /sw in meiner Suche /opt (für $PATH bzw. fink) und referenziere Dinge, die ich von port benötige, einschließlich /usr/local/bin, entweder buchstabiert, oder ich verwende gnat bash‘s, oder ich source eine alias-Datei für eine ganz andere Umgebung, wenn ich setup-Code schreibe.

Die Sache ist die, dass es wirklich davon abhängt, was Sie zu diesem Zeitpunkt wollen und brauchen.

Hier ist ein Beispiel für das ACL-Problem, das ich oben erwähnt habe.

Mit den standardmäßigen Ada-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

und mit den installierten OSX-Tools:

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

und

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

Sie erhalten ähnliche Ergebnisse mit brew und ich kenne nicht viele andere tar-Tools zu Hause, aber wer kann es sich leisten, dass etwas nach 6 Monaten wegen eines brew-Problems kaputt geht!

Es gibt eine ganze Reihe von guten Antworten hier. Hier ist meine:

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

Erspart Ihnen, für jedes Programm einen eigenen Alias zu erstellen, und als Bonus bleiben die Standardinstallationen zugänglich, falls Sie sie brauchen.

Funktioniert genauso, wenn Sie ZSH verwenden; tauschen Sie einfach bashrc gegen zshrc aus. Sie können my für _ oder sogar @ austauschen, um Tipparbeit zu sparen.

Anstatt überhaupt am PATH herumzupfuschen (was in meiner Geschichte Monate später wieder auf mich zurückkommt), habe ich einen Alias für git in meinem zsh-Verzeichnis für benutzerdefinierte Aliase hinzugefügt (~/.zshrc/custom/git_alias.zsh).

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

Sie können den folgenden Befehl in einem Terminal eingeben, er fügt das brew-Home-Verzeichnis + das /bin in den PATH Ihrer beliebigen SHELL “rc” init-Datei (bash, zsh, csh)

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

Enjoy !

Ich bevorzuge es, Änderungen an Umgebungsvariablen wie $PATH auf Benutzer zu beschränken, die diese Änderung tatsächlich wünschen. Daher füge ich einfach Folgendes zu ~/.bashrc hinzu:

export PATH="$(brew --prefix)/bin:$PATH"