Ik vond deze gerelateerde post erg behulpzaam. In plaats van de $PATH variabele te veranderen, laat het je gewoon je /etc/paths bestand aanpassen. Homebrew wil dat ik mijn PATH aanpas; geen idee hoe

Zodra ik de aanwijzingen had opgevolgd en /usr/local/bin boven /usr/bin had gezet, waren mijn problemen opgelost.

1. Op OS X, open Terminal
2. Type het commando: sudo vi /etc/paths
3. Voer je wachtwoord in als er om gevraagd wordt
4. Je krijgt een lijst met paden te zien. Bewerk ze zodat het /usr/local/bin pad boven het /usr/bin pad komt te staan
5. *Opslaan en afsluiten
6. Herstart Terminal

Hier is hoe de mijne eruit ziet nadat ik dat deed:

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

*Om op te slaan en te stoppen typ een dubbele punt (:), typ dan wq (om te schrijven en te stoppen op hetzelfde moment), gevolgd door Enter.

Je kunt het /etc/paths bestand ook openen in een grafische tekst editor en het op die manier bewerken.

Met dank aan fengd over op Stack Overflow voor zijn antwoord aldaar.

Dit antwoord is verouderd. De voorkeursvolgorde voor Homebrew PATH was zoals uitgelegd, maar dat is niet langer zo. De aanpak is echter meer algemeen toepasbaar, dus omwille van de interesse laat ik hem staan.

Dat moet je niet doen.

Homebrew houdt opzettelijk /usr/local/bin na /usr/bin in het pad voor maximale compatibiliteit. Het omkeren van de volgorde van deze directories in PATH door /etc/paths te bewerken zou betekenen dat alle programma’s waar dan ook op het systeem, ongeacht hoe ze gestart zijn, de Homebrew versie van een commando zullen krijgen. Maar sommige kunnen specifiek Apple’s versie verwachten, of gewoon niet in staat zijn om een nieuwere versie te gebruiken, etc.

Hoe kunnen we dit principe behouden en toch de Homebrew geïnstalleerde versie van git krijgen? Zoals het gezegde luidt, alle problemen kunnen worden opgelost met een laagje omleiding (behalve als er te veel lagen omleiding zijn). - Of in dit geval, zoals blijkt, twee lagen.

In het bijzonder maakt het deel uit van mijn Unix-gewoonten om een ~/bin directory te hebben die ik aan het begin van mijn PATH zet. Dit is een van de eerste bits in mijn .bashrc:

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

Dit controleert of PATH ~/bin bevat, en zo niet, zet ik het aan het begin. Met dat op zijn plaats, dan is selectief alleen de door Homebrew beheerde git voorrang geven boven de systeem versie (in plaats van iedere door Homebrew beheerde binary), en alleen voor je shell sessies (in plaats van alle programma’s die van waar dan ook gestart worden, inclusief GUI programma’s), zo simpel als symlinking:

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

Je zou /usr/local/Cellar/git/1.8.2.1/bin/git direct kunnen symlinken, maar dan zou je elke keer dat je een brew upgrade git doet (direct of indirect) je symlink moeten herstellen. Door te symlinken naar Homebrew’s vaste-locatie symlink, hoef je je daar geen zorgen over te maken.

Dus je voegt een directory toe aan je $HOME zodat je die kunt toevoegen aan je PATH zodat je kunt symlinken naar een symlink, en dat lost je probleem op en tovert een glimlach op Dr Seuss. Yo dawg ik hoor dat je van symlinks houdt dus we zetten een pad in je PATH zodat je kan symlinken terwijl je symlinkt.

Je hebt niets verkeerd gedaan, maar het lijkt vrij duidelijk dat als je /usr/local/bin in je pad had voor /usr/bin dit specifieke probleem weg zou gaan. De eenvoudigste oplossing is om dat te doen en iets als

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

in je ~/.bash_profile te zetten zodat alles wat Homebrew installeert eerst gevonden wordt. Dat is de manier waarop ik het heb ingesteld op mijn Mac, en het heeft gewerkt voor mij voor zo lang, echter, YMMV.

Het lijkt erop dat zij geloven dat het zou werken met /usr/local/bin als na /usr/bin, dus terwijl ik misschien mijn eigen $PATH heb verknoeid, kan ik zien waar hun documentatie tekort schiet:

Merk op dat je /usr/local/bin na /usr/bin moet zetten, omdat sommige programma’s verwachten dat ze de systeemversie van, bijvoorbeeld, ruby krijgen, en breken als ze de nieuwere Homebrew versie krijgen.

Van Discrepantie tussen wiki & brew doctor #10738 .  Merk op dat dit document verder gaat met te zeggen, “De FAQ (het bovenstaande citaat) verwijst naar de PATH instelling voor GUI apps; de dokter (het advies om /usr/local/bin voor /usr/bin in je PATH te zetten) verwijst naar de PATH instelling voor CLI apps.”

Ik ben het niet eens met jthomas’ antwoord. Het wijzigen van uw /etc/paths bestand zal de laadpaden voor alle programma’s wijzigen. Dit kan gevaarlijk zijn als een systeemapplicatie een specifieke versie van een binary verwacht te vinden, maar een andere versie vindt omdat jij je paths bestand hebt aangepast. Wijzig in plaats daarvan uw padvariabele in ~/.bashrc (of ~/.bash_profile). Dan zal je laadpad alleen in de terminal veranderen:

Voeg homebrew app toe aan PATH

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

Herlaad dan bash of source ~/.bashrc, en je bent klaar om te gaan. Aangezien het homebrew pad voor iets anders komt, zal bash de versie laden die je gedownload hebt met homebrew.

Zoals ik het begrijp, zet brew niets in /usr/local/bin dat botst (dezelfde naam heeft als) een door Apple gedistribueerd uitvoerbaar bestand. Daarom zou het hebben van /usr/local/bin in het pad voor /bin en /usr/bin geen probleem moeten zijn, omdat er geen naamsconflicten zouden moeten zijn. *Zie echter de problemen met ls en tar, en het gebruik van andere package aggregators zoals fink en port (MacPorts), hieronder.

Brew doet een van de twee dingen die ik ken die helpen bij het beheren van naamsconflicten:

1. Brew laat ongelinkte vaatjes in de Kelder. Om dingen te installeren, laat brew de gereedschappen waar ze zijn, en maakt symbolische links naar die gereedschappen in /usr/local/bin. Voor gereedschappen waar brew geen naamsconflict mee wil, maakt het geen symbolische link.
2. Voor veel, zo niet alle, standaardgereedschappen die ook in /bin en /usr/bin zitten, plaatst brew een “g” voor de link in /usr/local/bin, dus om bijvoorbeeld een ls uit te voeren met een brouwversie, gebruik gls. Doe eenvoudig een ls -l in /usr/local/bin en zoek naar de gelinkte bestanden - dat zijn degene die brew daar neerzet. Opmerking: De brew geïnstalleerde gereedschappen die met hun echte naam benaderd moeten worden, staan in /usr/local/Cellar/coreutils/8.21/libexec/gnubin.

Ik zet /usr/local/bin niet in mijn pad om twee redenen - die redenen staan onderaan mijn antwoord.

Om de naambotsingen in je systeem te beoordelen, gebruik je brew doctor en zoek je naar deze sectie - Hier is de uitvoer van brew doctor van belang:

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

De reden waarom ik brew‘s tools niet op de eerste plaats zet, in feite helemaal niet, is omdat de brew geïnstalleerde ls en tar commando’s de bestandssysteem ACL niet goed afhandelen, in feite, de laatste keer dat ik controleerde (en dat was vorige week), werd er helemaal niet mee omgegaan. Dit is een GROOT probleem, en om het helemaal te vermijden, samen met het geassocieerde man pagina configuratie probleem dat gepaard gaat met het juist instellen van de $PATH, zorg ik ervoor dat ik de OSX gerelateerde tools, vooral die in /bin en /usr/bin, eerst zet.

Een andere reden waarom ik /usr/local/bin helemaal niet in mijn pad zet is omdat brew niet goed samenwerkt met anderen, en fink en port (MacPorts) hebben op dit moment veel meer ondersteunde pakketten die ik NOW nodig heb. Ik kan bijvoorbeeld gnome-terminal krijgen met fink, maar het zou een grote moeite zijn om een formule te construeren en hetzelfde te doen met brew. Dus, ik houd /sw en /opt in mijn zoek $PATH (voor fink en port, respectievelijk) en verwijs naar dingen die ik nodig heb van /usr/local/bin, inclusief gnat, ofwel gespeld, of ik gebruik bash alias’s, of ik source een setup bestand voor een geheel andere omgeving wanneer ik Ada code schrijf.

Het ding is, het hangt echt af van wat je wilt en nodig hebt op het moment.

Hier is een voorbeeld van het ACL probleem dat ik hierboven noemde.

Met de standaard 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

en met de brew geïnstalleerde tools:

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

en

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

Je zult vergelijkbare resultaten krijgen met tar en ik ken niet veel andere brew tools, maar wie kan het zich veroorloven om 6 maanden later iets kapot te laten gaan door een ACL probleem!

Er zijn een heleboel goede antwoorden hier. Hier is het mijne:

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

Bespaart je de moeite om voor elk programma een aparte alias aan te maken, en als bonus laat het de standaard installaties toegankelijk voor het geval je ze nodig hebt.

Werkt precies hetzelfde als je ZSH gebruikt; verwissel gewoon bashrc voor zshrc. Je kunt my verwisselen voor _ of zelfs @ om te besparen op typewerk.

In plaats van te knoeien met het PATH (wat in mijn geschiedenis maanden later terug komt om me te verbranden) heb ik een alias voor git toegevoegd in mijn zsh custom aliassen directory (~/.zshrc/custom/git_alias.zsh).

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

Je kunt het volgende commando in een terminal uitvoeren, het zal de brew home directory + de /bin toevoegen aan het PATH van je welk SHELL “rc” init bestand dan ook (bash, zsh, csh)

Enjoy !

Ik geef er de voorkeur aan om veranderingen aan environvent variabelen zoals $PATH te beperken tot gebruikers die de verandering ook echt willen. Dus, ik voeg gewoon het volgende toe aan ~/.bashrc:

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