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.
Sudo vi /etc/paths
/usr/local/bin
soit entré au-dessus du chemin /usr/bin
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/bin
after/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/bin
après/usr/bin
car 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:
Brew
laisse 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 lesquels brew
ne souhaite pas une collision de noms, il ne crée pas de lien symbolique./bin
et /usr/bin
, brew
préfixe le lien dans /usr/local/bin
avec un "g", par exemple, pour exécuter un ls
avec une version brassée, utilisez gls
. Faites simplement un ls -l
dans /usr/local/bin
et recherchez les fichiers liés - ce sont ceux que brew
a mis là. Remarque: Les outils installés brew
auxquels 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 bash
alias
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 !