Comment définir la variable PATH sur mon Mac afin de retrouver les outils installés par Hombrew?

Essayer de configurer Homebrew sur un nouveau Mac (sur les Mac précédents, j'installerais les packages à partir des sources).

Le premier paquet que j'ai essayé d'installer était Git:

$ brew install git

L'installation s'est bien déroulée, mais which gitmontre toujours celle /usr/bin/gitqui a été livrée avec Lion (je pense?). Et pas celui /usr/local/bin/gitqui vient d'être installé.

$ echo $PATH
/Users/meltemi/.rvm/gems/ruby-1.9.2-p290@rails31/bin:/Users/meltemi/.rvm/gems/ruby-1.9.2-p290@global/bin:/Users/meltemi/.rvm/rubies/ruby-1.9.2-p290/bin:/Users/michael/.rvm/bin:/usr/local/mysql/bin:/opt/subversion/bin:/Developer/Additions/checker/:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin

Comme vous pouvez voir les /usr/binvaleurs par défaut avant /usr/local/bindans le$PATH

Donc, je suis confus! Je pensais que le but de HomeBrew (et les créateurs semblent se vanter) était de ne pas jouer avec la $PATHvariable!?!

Alors, qu'est-ce que j'ai mal fait?

J'ai trouvé ce post connexe très utile. Au lieu de changer la $PATHvariable, vous devez simplement éditer votre /etc/pathsfichier.

Homebrew veut que je modifie mon PATH; aucune idée comment

Dès que j'ai suivi les instructions et mis /usr/local/binci /usr/bin- dessus , mes problèmes ont été résolus.

1. Sous OS X, ouvrez Terminal
2. Tapez la commande: sudo vi /etc/paths
3. Entrez votre mot de passe si on vous le demande
4. Vous verrez une liste de chemins. Editez-les pour que le /usr/local/binchemin soit entré au-dessus du /usr/binchemin
5. *Sauvegarder et quitter
6. Redémarrer le terminal

Voici à quoi ressemble le mien après l'avoir fait:

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

* Pour enregistrer et quitter, tapez deux points ( :), puis tapez wq(pour écrire et quitter en même temps), suivi de Enter.

Vous pouvez également ouvrir le /etc/pathsfichier dans un éditeur de texte graphique et le modifier de cette façon.

Crédit à fengd chez Stack Overflow pour sa réponse là-bas.

Cette réponse est obsolète. La PATHcommande préférée de Homebrew était celle décrite précédemment, mais ce n’est plus le cas. Cependant, l'approche est plus généralement applicable, donc pour l'intérêt, je laisse tomber.

Tu ne devrais pas.

Homebrew maintient intentionnellement /usr/local/bin après /usr/bin dans le chemin pour une compatibilité maximale. Si vous inversez l'ordre de ces répertoires en le PATHmodifiant /etc/paths, tous les programmes situés sur le système, quel que soit leur mode de démarrage, obtiendront la version Homebrew d'une commande. Mais certains peuvent spécifiquement s'attendre à la version d'Apple, ou tout simplement ne pas pouvoir utiliser une version plus récente, etc.

Comment préserver ce principe et toujours obtenir la version de Homebrew installée git? Comme dit le proverbe, tous les problèmes peuvent être résolus avec une couche d'indirection (sauf d'avoir trop de couches d'indirection). - ou dans ce cas, il se trouve que deux couches.

En particulier, cela faisait partie de mes habitudes Unix de disposer d’un ~/binrépertoire que j’ai mis au début de mon répertoire PATH. C'est l'un des premiers bits de mon .bashrc:

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

Ceci vérifie si PATHcontient ~/bin, et sinon, le préfixe. Cela fait en sorte que, de manière sélective, seule la version gérée par Homebrew soit gitprioritaire sur la version système (au lieu de chaque binaire géré par Homebrew), et uniquement pour vos sessions shell (au lieu de tous les programmes démarrés de n’importe où, y compris les programmes à interface graphique), aussi simple que de la relier:

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

Vous pouvez créer /usr/local/Cellar/git/1.8.2.1/bin/gitun lien symbolique directement, mais vous devrez alors le corriger à chaque fois que vous faites un brew upgrade git(directement ou indirectement). En établissant un lien avec le lien symbolique de Homebrew pour les emplacements fixes, vous n’aurez pas à vous en préoccuper.

Donc, vous ajoutez un répertoire à votre $HOMEafin que vous puissiez l'ajouter à votre PATHafin que vous puissiez lien symbolique vers un lien symbolique, et cela résout votre problème et fait sourire le Dr Seuss. Je vous attends, vous aimez les liens symboliques; nous vous mettons donc un chemin PATHpour vous permettre de créer un lien symbolique pendant que vous le faites.

Vous n'avez rien fait de mal, mais il semble assez clair que si vous aviez /usr/local/binsur votre chemin avant que /usr/bince problème spécifique ne disparaisse. La solution la plus simple est de le faire et de mettre quelque chose comme

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

dans votre ~/.bash_profileordinateur, tout ce que Homebrew installe se trouve en premier. C'est comme ça que je l'ai installé sur mon Mac, et cela a fonctionné pour moi pendant si longtemps, cependant, YMMV.

Il ne semble qu'ils croient qu'il travaillerait avec /usr/local/binêtre après /usr/bin , si bien que je pourrais avoir sali mon propre $PATH, je peux voir où leur documentation manque:

Notez que vous devriez mettre /usr/local/binaprès /usr/bin car certains programmes s’attendront à obtenir la version système de Ruby par exemple, et casseront s’ils obtiennent la version plus récente de Homebrew.

De la discordance entre le wiki et le médecin de brassage # 10738 . Notez que ce document poursuit: "La FAQ (la citation ci-dessus) fait référence au paramètre PATH pour les applications à interface graphique; le médecin (le conseil à mettre en /usr/local/binavant /usr/bin dans votre PATH) fait référence au paramètre PATH pour les applications CLI."

Je ne suis pas d'accord avec la réponse de Jthomas. La modification de votre fichier / etc / path modifiera les chemins de chargement de tous les programmes. Cela pourrait être dangereux si une application système s'attend à trouver une version spécifique d'un binaire mais trouve une version différente parce que vous avez modifié votre fichier de chemins. Changez plutôt votre variable de chemin dans ~ / .bashrc (ou ~ / .bash_profile). Ensuite, votre chemin de chargement ne changera que dans le terminal:

# Ajouter une application homebrew à l'
export PATH PATH = / chemin / vers / homebrew / app / bin: $ PATH

Rechargez ensuite bash ou source ~/.bashrc, et vous voilà prêt à partir. Comme le chemin homebrew vient avant toute autre chose, bash chargera la version que vous avez téléchargée avec homebrew.

Si je comprends bien, brewrien ne se met dans ce /usr/local/binqui entre en collision (a le même nom que) un exécutable distribué Apple. Par conséquent, avoir /usr/local/bindans le chemin auparavant /binet /usr/binne devrait pas être un problème, car il ne devrait y avoir aucune collision de noms. * Cependant, voyez les problèmes avec lset tar, et utilisez d'autres agrégateurs de paquetages comme finket port(MacPorts), de manière plus détaillée.

Brew Est-ce que l'une des deux choses que je connais qui aide à gérer les collisions de noms:

1. Brewlaisse des fûts non liés dans la cave. Pour installer des éléments, brasser laisse les outils là où ils sont et crée des liens symboliques vers ces outils dans /usr/local/bin. Pour les outils qui brewne veulent pas de conflit de nom, cela ne crée pas de lien symbolique.
2. Pour la plupart des outils standard qui sont aussi dans /binet /usr/bin, brewpréfixe le lien /usr/local/binavec un "g", par exemple, pour effectuer une lsversion avec une infusion, utilisez gls. Il suffit de faire un ls -ldans /usr/local/binet recherchez les fichiers liés - ce sont ceux brewmis là. Remarque: Les brewoutils installés auxquels il faut accéder par leur vrai nom se trouvent dans /usr/local/Cellar/coreutils/8.21/libexec/gnubin.

Je ne mets pas /usr/local/binsur mon chemin pour deux raisons - ces raisons sont au bas de ma réponse.

Pour évaluer les collisions de noms dans votre système, utilisez brew doctoret recherchez cette section - Voici la brew doctorsortie d'intérêt de:

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

La raison pour laquelle je ne mets pas d' brewabord les outils, en fait, pas du tout, c'est parce que les commandes brewinstallées lset tarne gèrent pas correctement les ACL du système de fichiers. En fait, la dernière fois que j'ai vérifié (ce qui était la semaine dernière), elles n'étaient pas t pas manipulé du tout . C’est un gros problème, et pour l’éviter complètement, ainsi que le manproblème de configuration de page associé à la balise et à la définition $PATHcorrecte, je m’assure de mettre les OSXoutils associés, en particulier ceux trouvés dans /binet /usr/bin, d’abord.

Une autre raison pour laquelle je ne mets même pas du tout /usr/local/binsur mon chemin est que je brewne joue pas très bien avec les autres, et finkque port(MacPorts) propose actuellement davantage de packages pris en charge dont j'ai besoin maintenant . Par exemple, je peux obtenir gnome-terminalavec fink, mais ce serait un gros effort pour construire une formule et faire la même chose avec brew. Donc, je garde /swet /optdans ma recherche $PATH(pour finket portrespectivement) et référence les éléments dont j'ai besoin /usr/local/bin, y compris gnat, soit épelés, soit ceux que j'utilise bash alias, ou je source un setupfichier pour un environnement totalement différent lors de l'écriture de Adacode.

Le fait est que cela dépend vraiment de ce que vous voulez et de ce dont vous avez besoin à ce moment-là.

Voici un exemple du problème ACL que j'ai mentionné ci-dessus.

Avec les OSXoutils standards :

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

et avec les brewoutils installés:

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

et

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

Vous obtiendrez des résultats similaires avec taret je ne connais pas beaucoup d’autres brewoutils, mais qui peut se permettre d’obtenir quelque chose en moins 6 mois à cause d’un ACLproblème!

Il y a une foule de bonnes réponses ici. Voici la mienne:

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

Cela vous évite de créer un alias distinct pour chaque programme et, en prime, de rendre les installations par défaut accessibles au cas où vous en auriez besoin.

Fonctionne de la même manière si vous utilisez ZSH; il suffit de changer bashrcpour zshrc. Vous pouvez passer en mypour _ou même @faire des économies sur la saisie.

Plutôt que de jouer avec le PATH (ce qui dans mon histoire revient me brûler des mois plus tard), j'ai ajouté un alias pour git dans mon répertoire d'alias personnalisé zsh (~ / .zshrc / custom / git_alias.zsh).

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

Je préfère limiter les modifications aux variables environnementales, comme $PATHpour les utilisateurs qui souhaitent réellement les modifier. Ainsi, j'ajoute simplement ce qui suit ~/.bashrc:

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

Vous pouvez émettre la commande suivante dans un terminal, elle ajoutera le répertoire de base du brassage + le / bin dans le chemin PATH de votre fichier d'initialisation "rc" quel que soit votre shell (bash, zsh, csh)

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

Prendre plaisir !