Comment définir la variable PATH sur mon Mac afin que les outils installés par Homebrew soient détectés?
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 git affiche toujours celui de /usr/bin/git fourni avec Lion (je pense?). Et pas celui dans /usr/local/bin/git qui 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 le voir par défaut /usr/bin avant /usr/local/bin dans le $PATH
Donc, je suis confus! Je pensais que le but de HomeBrew (et les créateurs semblent se vanter) était qu'il n'était pas nécessaire de jouer avec la variable $PATH!?!
Alors, qu'est-ce que j'ai mal fait?
J'ai trouvé ce post connexe très utile. Au lieu de changer la variable $PATH, il vous suffit de modifier votre fichier /etc/paths.
Homebrew veut que je modifie mon PATH; aucune idée de comment
Dès que j'ai suivi les instructions et mis /usr/local/bin ci-dessus /usr/bin, mes problèmes ont été résolus.
- Sous OS X, ouvrez Terminal
- Tapez la commande:
Sudo vi /etc/paths - Entrez votre mot de passe si on vous le demande
- Vous verrez une liste de chemins. Modifiez-les de sorte que le chemin
/usr/local/binsoit entré au-dessus du chemin/usr/bin - *Sauvegarder et quitter
- 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 fichier /etc/paths dans un éditeur de texte graphique et le modifier ainsi.
Nous remercions fengd de Stack Overflow pour sa réponse là-bas.
Cette réponse est obsolète. Le classement préféré de Homebrew PATH était celui qui avait été expliqué, mais ce n’est plus le cas. Cependant, l’approche est plus généralement applicable et, par conséquent, je l’abandonne.
Tu ne devrais pas.
Homebrew conserve intentionnellement /usr/local/binafter/usr/bin dans le chemin pour une compatibilité maximale. Inverser l’ordre de ces répertoires dans PATH en éditant /etc/paths signifierait que les tous 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 être en mesure d'utiliser une version plus récente, etc.
Comment préserver ce principe et toujours obtenir la version de git installée par Homebrew? 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 répertoire ~/bin que j’ai mis au début de ma PATH. C'est l'un des premiers bits de mon .bashrc:
[[ :$PATH: == *:$HOME/bin:* ]] || PATH=$HOME/bin:$PATH
Ceci vérifie si PATH contient ~/bin, et sinon, le préfixe. Cela fait en sorte que la valeur git gérée par Homebrew soit prioritaire sur la version du système (au lieu de tous binaire gérée par Homebrew), et uniquement pour vos sessions Shell (au lieu de tout) programmes démarrés de n’importe où, y compris les programmes GUI), est aussi simple que de le lier de façon symbolique:
ln -s /usr/local/bin/git ~/bin/git
Vous pouvez lien symbolique /usr/local/Cellar/git/1.8.2.1/bin/git directement, mais vous devrez alors corriger votre lien symbolique chaque fois que vous faites un brew upgrade git (directement ou indirectement). En établissant un lien avec le lien symbolique d’emplacement fixe de Homebrew, vous n’aurez plus à vous en soucier.
Vous ajoutez donc un répertoire à votre $HOME pour pouvoir y ajouter votre PATH afin que vous puissiez créer un lien symbolique vers un lien symbolique, ce qui résout votre problème et fait sourire le Dr Seuss. Je vous attends, vous aimez les liens symboliques; nous avons donc placé un chemin dans votre PATH afin que vous puissiez 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/bin dans votre chemin avant /usr/bin, ce problème spécifique disparaîtrait. La solution la plus simple est de le faire et de mettre quelque chose comme
export PATH=/usr/local/bin:$PATH
dans votre ~/.bash_profile de sorte que 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 semble qu'ils croient que cela fonctionnerait avec /usr/local/bin étant après /usr/bin, alors, bien que j'aie pu maquiller mon propre $PATH, je peux voir où leur documentation manque:
Notez que vous devriez mettre
/usr/local/binaprès/usr/bincar certains programmes s'attendent à obtenir la version système de Ruby, par exemple, et se cassent s'ils récupèrent la version plus récente de Homebrew.
De Différence entre le wiki et le médecin de brassage # 10738 . Notez que ce document poursuit: "La FAQ (citation ci-dessus) fait référence au paramètre PATH pour les applications à interface graphique; le médecin (l’avis de placer /usr/local/bin devant /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, car 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 l'application homebrew à PATH
export 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, brew ne met rien dans /usr/local/bin qui entre en collision (porte le même nom que) avec un exécutable distribué Apple. Par conséquent, avoir /usr/local/bin dans le chemin avant /bin et /usr/bin ne devrait pas être un problème, car il ne devrait y avoir aucune collision de noms. * Cependant, voyez les problèmes avec ls et tar, et utilisez d'autres agrégateurs de paquets comme fink et port (MacPorts), de la manière indiquée ci-dessous.
Brew effectue l'une des deux choses que je connaisse pour vous aider à gérer les collisions de noms:
Brewlaisse des fûts non liés dans la cave. Pour installer des éléments, brasse laisse les outils là où ils se trouvent et crée des liens symboliques vers ces outils dans/usr/local/bin. Pour les outils avec lesquelsbrewne souhaite pas une collision de noms, il ne crée pas de lien symbolique.- Pour la plupart des outils standard qui sont également dans
/binet/usr/bin,brewpréfixe le lien dans/usr/local/binavec un "g", par exemple, pour exécuter unlsavec une version brassée, utilisezgls. Faites simplement unls -ldans/usr/local/binet recherchez les fichiers liés - ce sont ceux quebrewa mis là. Remarque: Les outils installésbrewauxquels il faut accéder par leur nom réel se trouvent dans/usr/local/Cellar/coreutils/8.21/libexec/gnubin.
Je ne mets pas /usr/local/bin dans mon chemin pour deux raisons - ces raisons sont au bas de ma réponse.
Pour évaluer les conflits de noms dans votre système, utilisez brew doctor et recherchez cette section - Voici la sortie d'intérêt de brew doctor:
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'abord les outils de brew en fait, pas du tout, c'est parce que les commandes brew installées ls et tar ne gèrent pas correctement la liste de contrôle d'accès du système de fichiers. En fait, la dernière fois que j'ai vérifié (ce qui était la semaine dernière) , ils n'ont pas du tout été manipulés . C’est un gros problème, et pour l’éviter complètement, ainsi que le problème de configuration de la page man associé à la définition de $PATH, je m’assure de mettre en premier les outils liés à OSX, en particulier ceux trouvés dans /bin et /usr/bin.
Une autre raison pour laquelle je ne mets même pas du tout /usr/local/bin dans mon chemin est que brew ne fonctionne pas bien avec les autres, et que fink et port (MacPorts) ont beaucoup plus de paquets supportés actuellement que j'ai besoin deMAINTENANT. Par exemple, je peux obtenir gnome-terminal avec fink, mais ce serait un gros effort de construire une formule et de faire la même chose avec brew. Donc, je garde /sw et /opt dans ma recherche $PATH (pour fink et port, respectivement) et référence les éléments dont j'ai besoin de /usr/local/bin, y compris gnat, soit explicités, soit j'utilise bashalias ou le fichier source setup environnement lorsque j'écris le code Ada.
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 outils OSX standard:
$ /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 outils installés brew:
$ /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 tar et je ne connais pas beaucoup d’autres outils brew, mais qui peut se permettre de faire quelque chose de cassé 6 mois plus tard à cause d’un problème ACL!
Il y a une foule de bonnes réponses ici. Voilà le mien:
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; changez simplement bashrc pour zshrc. Vous pouvez désactiver my pour _ ou même @ pour économiser 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 apportées aux variables environvent telles que $PATH aux utilisateurs qui souhaitent réellement les modifier. Ainsi, j'ajoute simplement ce qui suit à ~/.bashrc:
export PATH="$(brew --prefix)/bin:$PATH"
Vous pouvez lancer la commande suivante dans un terminal, cela ajoutera le répertoire de base du brassage + le/bin dans le chemin PATH de votre fichier d'initialisation "rc" quel que soit le shell (bash, zsh, csh)
echo "export PATH="'$PATH:$(brew --prefix)/bin' >> ~/.$(basename $Shell)rc
Prendre plaisir !