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
montre toujours celle /usr/bin/git
qui a été livrée avec Lion (je pense?). Et pas celui /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 voir les /usr/bin
valeurs par défaut 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 de ne pas jouer avec la $PATH
variable!?!
Alors, qu'est-ce que j'ai mal fait?
If you choose /usr/local, everything 'just works!'
laquelle je dois me demander ce qui me manque ... parce que ça ne marche pas "tout simplement".Réponses:
J'ai trouvé ce post connexe très utile. Au lieu de changer la
$PATH
variable, vous devez simplement éditer votre/etc/paths
fichier.Homebrew veut que je modifie mon PATH; aucune idée comment
Dès que j'ai suivi les instructions et mis
/usr/local/bin
ci/usr/bin
- dessus , mes problèmes ont été résolus.sudo vi /etc/paths
/usr/local/bin
chemin soit entré au-dessus du/usr/bin
cheminVoici à quoi ressemble le mien après l'avoir fait:
* Pour enregistrer et quitter, tapez deux points (
:
), puis tapezwq
(pour écrire et quitter en même temps), suivi de Enter.Vous pouvez également ouvrir le
/etc/paths
fichier 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.
la source
path_helper
et/etc/paths.d
.Cette réponse est obsolète. La
PATH
commande 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 lePATH
modifiant/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
~/bin
répertoire que j’ai mis au début de mon répertoirePATH
. C'est l'un des premiers bits de mon.bashrc
:Ceci vérifie si
PATH
contient~/bin
, et sinon, le préfixe. Cela fait en sorte que, de manière sélective, seule la version gérée par Homebrew soitgit
prioritaire 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:Vous pouvez créer
/usr/local/Cellar/git/1.8.2.1/bin/git
un lien symbolique directement, mais vous devrez alors le corriger à chaque fois que vous faites unbrew 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
$HOME
afin que vous puissiez l'ajouter à votrePATH
afin 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 cheminPATH
pour vous permettre de créer un lien symbolique pendant que vous le faites.la source
ln
commande. Le premier chemin est la cible, et le second est le lien symboliqueexport PATH="/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin"
Vous n'avez rien fait de mal, mais il semble assez clair que si vous aviez
/usr/local/bin
sur votre chemin avant que/usr/bin
ce problème spécifique ne disparaisse. La solution la plus simple est de le faire et de mettre quelque chose commedans votre
~/.bash_profile
ordinateur, 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: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/bin
avant/usr/bin
dans votre PATH) fait référence au paramètre PATH pour les applications CLI."la source
/usr/local/bin
s dans mon$PATH
? Je le crois. Je me demande si nous devrions plutôt modifier l’ordre des chemins par défaut/etc/paths
ou le contenu de/etc/paths.d
? Mais cela affectera tous les utilisateurs ... peut-être pas une mauvaise chose. Quoi qu'il en soit, je voulais juste voir comment d'autres personnes ont abordé cette question.PATH
(de la manière que vous avez choisie) pour la faire/usr/local/bin
précéder/usr/bin
. Personnellement, je mets à jour monPATH
dans.bash_profile
comme suggéré ici./usr/local/bin
même si elles traînent/usr/bin
dans le chemin. Mais les applications graphiques ont besoin de chouchous? Il semblerait que toutes les applications, avec ou sans interface graphique, ont besoin de nous pour ajuster la variable $ PATH. Alors, que me manque-t-il (ou les créateurs Homebrew)?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:
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.la source
.bashrc
n'est pas chargé par défaut. Avez-vous le source manuellement?.bashrc
j’étais habitué à en avoir un, alors je le trouve dans ma source.bash_profile
. Si vous ne souhaitez pas créer le fichier rc, vous pouvez ajouter la commande à votre.bash_profile
.Si je comprends bien,
brew
rien ne se met dans ce/usr/local/bin
qui entre en collision (a le même nom que) un exécutable distribué Apple. Par conséquent, avoir/usr/local/bin
dans le chemin auparavant/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 avecls
ettar
, et utilisez d'autres agrégateurs de paquetages commefink
etport
(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:Brew
laisse 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 quibrew
ne veulent pas de conflit de nom, cela ne crée pas de lien symbolique./bin
et/usr/bin
,brew
préfixe le lien/usr/local/bin
avec un "g", par exemple, pour effectuer unels
version avec une infusion, utilisezgls
. Il suffit de faire unls -l
dans/usr/local/bin
et recherchez les fichiers liés - ce sont ceuxbrew
mis là. Remarque: Lesbrew
outils 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/bin
sur 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 doctor
et recherchez cette section - Voici labrew doctor
sortie d'intérêt de:La raison pour laquelle je ne mets pas d'
brew
abord les outils, en fait, pas du tout, c'est parce que les commandesbrew
installéesls
ettar
ne 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 leman
problème de configuration de page associé à la balise et à la définition$PATH
correcte, je m’assure de mettre lesOSX
outils associés, en particulier ceux trouvés dans/bin
et/usr/bin
, d’abord.Une autre raison pour laquelle je ne mets même pas du tout
/usr/local/bin
sur mon chemin est que jebrew
ne joue pas très bien avec les autres, etfink
queport
(MacPorts) propose actuellement davantage de packages pris en charge dont j'ai besoin maintenant . Par exemple, je peux obtenirgnome-terminal
avecfink
, mais ce serait un gros effort pour construire une formule et faire la même chose avecbrew
. Donc, je garde/sw
et/opt
dans ma recherche$PATH
(pourfink
etport
respectivement) et référence les éléments dont j'ai besoin/usr/local/bin
, y comprisgnat
, soit épelés, soit ceux que j'utilisebash
alias
, ou je source unsetup
fichier pour un environnement totalement différent lors de l'écriture deAda
code.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
OSX
outils standards :et avec les
brew
outils installés:et
Vous obtiendrez des résultats similaires avec
tar
et je ne connais pas beaucoup d’autresbrew
outils, mais qui peut se permettre d’obtenir quelque chose en moins 6 mois à cause d’unACL
problème!la source
Il y a une foule de bonnes réponses ici. Voici la mienne:
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
bashrc
pourzshrc
. Vous pouvez passer enmy
pour_
ou même@
faire des économies sur la saisie.la source
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'
la source
Je préfère limiter les modifications aux variables environnementales, comme
$PATH
pour les utilisateurs qui souhaitent réellement les modifier. Ainsi, j'ajoute simplement ce qui suit~/.bashrc
:la source
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 !
la source