2011-08-17 19:36:41 +0000 2011-08-17 19:36:41 +0000
86
86

Jak powinienem ustawić zmienną PATH na moim Macu, aby narzędzia zainstalowane w Hombrew zostały znalezione?

Próbuję skonfigurować Homebrew na nowym Macu (na poprzednich Macach instalowałem pakiety ze źródła).

Pierwszym pakietem, który próbowałem zainstalować był Git:

$ brew install git

Instalacja przebiegła OK, ale w which git nadal wyświetla się ten z /usr/bin/git, który przyszedł razem z Lionem (chyba?). A nie ten w /usr/local/bin/git, który został właśnie zainstalowany.

$ 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

Jak widzisz, /usr/bin domyślnie ustawia się przed /usr/local/bin w katalogu $PATH

Więc, jestem zdezorientowany! Myślałem, że sensem HomeBrew (i czymś, czym twórcy zdają się chwalić) jest to, że nie musisz mieszać ze zmienną $PATH!?

Więc, co zrobiłem źle?

Odpowiedzi (9)

79
79
79
2013-01-13 22:35:02 +0000

Znalazłem ten powiązany post, aby być bardzo pomocnym. Zamiast zmieniać zmienną $PATH, po prostu edytuj swój plik /etc/paths. Homebrew chce, żebym zmienił PATH; nie mam pojęcia jak

Jak tylko podążyłem za wskazówkami i umieściłem /usr/local/bin powyżej /usr/bin, moje problemy zostały rozwiązane.

  1. Na OS X, otwórz Terminal
  2. Wpisz polecenie: sudo vi /etc/paths
  3. Wpisz swoje hasło, jeśli zostaniesz o nie poproszony
  4. Zobaczysz listę ścieżek. Edytuj je tak, aby ścieżka /usr/local/bin była wpisana nad ścieżką /usr/bin
  5. *Zapisz i zakończ pracę
  6. Uruchom ponownie Terminal

Oto jak wygląda mój po wykonaniu tych czynności:

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

Aby zapisać i wyjść wpisz dwukropek (:), następnie wpisz wq (aby zapisać i wyjść jednocześnie), po czym Enter.

Możesz również otworzyć plik /etc/paths w graficznym edytorze tekstu i edytować go w ten sposób.

Kredyt dla fengd over w Stack Overflow za jego odpowiedź tam.

29
29
29
2013-04-09 23:28:21 +0000

Ta odpowiedź jest nieaktualna. Preferowane zamawianie Homebrew PATH było kiedyś takie, jak wyjaśniono, ale to już nie jest prawdą. Jednak podejście jest bardziej ogólnie stosowane, więc ze względu na zainteresowanie pozostawiam to w górę.


Nie powinieneś.

Homebrew celowo trzyma /usr/local/bin po /usr/bin w ścieżce dla maksymalnej kompatybilności. Odwrócenie kolejności tych katalogów w PATH przez edycję /etc/paths oznaczałoby, że wszystkie programy gdziekolwiek w systemie, bez względu na to jak zostały uruchomione, otrzymają Homebrajską wersję polecenia. Ale niektóre z nich mogą oczekiwać wersji Apple, lub po prostu nie być w stanie używać nowszej wersji, itp.

Jak zachować tę zasadę i nadal otrzymywać Homebrew-instalowaną wersję git? Jak mówi przysłowie, wszystkie problemy można rozwiązać za pomocą warstwy pośredniej (z wyjątkiem posiadania zbyt wielu warstw pośrednich). - Albo w tym przypadku, jak się okazuje, dwóch warstw.

Konkretnie, częścią moich uniksowych przyzwyczajeń było posiadanie katalogu ~/bin, który umieszczam na początku mojego PATH. To jest jeden z pierwszych bitów w moim .bashrc:

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

To sprawdza, czy PATH zawiera ~/bin, a jeśli nie, to go poprzedza. Mając to na miejscu, selektywne uczynienie tylko Homebrew-managed git nadrzędnym w stosunku do wersji systemowej (zamiast każdej Homebrew-managed binarnej), i tylko dla sesji powłoki (zamiast wszystkich programów uruchamianych z dowolnego miejsca, włączając w to programy GUI), jest tak proste jak symlinking:

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

Mógłbyś_ symlinkować /usr/local/Cellar/git/1.8.2.1/bin/git bezpośrednio, ale wtedy musiałbyś poprawiać swoje symlinki za każdym razem, gdy wykonasz brew upgrade git (bezpośrednio lub pośrednio). Dzięki symlinkowaniu do symlinka Homebrew o stałej lokalizacji, nie musisz się o to martwić.

Więc dodajesz katalog do swojego $HOME, więc możesz dodać go do swojego PATH, więc możesz symlinkować do symlinka, a to rozwiązuje twój problem i wywołuje uśmiech na twarzy Dr Seussa. Yo dawg I herd you like symlinks so we put a path in your PATH so you can symlink while you symlink.

18
18
18
2011-08-17 19:42:55 +0000

Nie zrobiłeś nic złego, ale wydaje się dość oczywiste, że gdybyś miał /usr/local/bin w ścieżce przed /usr/bin, ten konkretny problem by zniknął. Najłatwiejszym rozwiązaniem jest właśnie to zrobić i umieścić coś takiego jak

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

w ~/.bash_profile, aby wszystko co instaluje Homebrew było znajdowane jako pierwsze. To jest sposób, w jaki mam to ustawione na moim Macu, i to działało dla mnie przez tak długi czas, jednak YMMV.

Wygląda na to, że wierzą, że będzie działać z /usr/local/bin będącym po /usr/bin, więc podczas gdy ja mogłem zepsuć moje własne $PATH, widzę, gdzie brakuje ich dokumentacji:

Zauważ, że powinieneś umieścić /usr/local/bin po /usr/bin, ponieważ niektóre programy będą oczekiwać, że otrzymają wersję systemową, np. ruby, i zepsują się, jeśli otrzymają nowszą wersję Homebrew.

Z Rozbieżność między wiki i brew doctor #10738 .  Zauważ, że ten dokument mówi dalej, “The FAQ (powyższy cytat) odnosi się do ustawienia PATH dla aplikacji GUI; doktor (rada, aby umieścić /usr/local/bin przed /usr/bin w PATH) odnosi się do ustawienia PATH dla aplikacji CLI.”

6
6
6
2013-04-03 19:28:03 +0000

Nie zgadzam się z odpowiedzią jthomasa. Edycja pliku /etc/paths spowoduje zmianę ścieżek ładowania dla wszystkich programów. Może to być niebezpieczne, jeśli aplikacja systemowa spodziewa się znaleźć określoną wersję binarną, ale znajduje inną wersję, ponieważ edytowałeś swój plik ścieżek. Zamiast tego, zmień zmienną ścieżki w ~/.bashrc (lub ~/.bash_profile). Wtedy ścieżka ładowania będzie się zmieniać tylko wewnątrz terminala:

Add homebrew app to PATH

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

Następnie przeładuj bash lub source ~/.bashrc, i możesz zaczynać. Ponieważ ścieżka do homebrew pojawia się przed czymkolwiek innym, bash załaduje wersję, którą pobrałeś za pomocą homebrew.

5
5
5
2014-01-03 22:07:43 +0000

Jak rozumiem, brew nie umieszcza niczego w /usr/local/bin, co koliduje (ma taką samą nazwę jak) dystrybuowane przez Apple pliki wykonywalne. Dlatego posiadanie /usr/local/bin w ścieżce przed /bin i /usr/bin nie powinno być problemem, ponieważ nie powinno być żadnych kolizji nazw. *Jednakże, zobacz problemy z ls i tar, oraz używanie innych agregatorów pakietów, takich jak fink i port (MacPorts), poniżej.

Brew robi jedną z dwóch rzeczy, o których wiem, że pomagają zarządzać kolizjami nazw:

  1. **Aby zainstalować rzeczy, brew pozostawia narzędzia tam, gdzie są, i tworzy dowiązania symboliczne do tych narzędzi w Brew. Dla narzędzi, z którymi /usr/local/bin nie chce mieć kolizji nazw, nie tworzy dowiązania symbolicznego.
  2. W przypadku wielu, jeśli nie wszystkich, standardowych narzędzi, które są również w brew i /bin, /usr/bin poprzedza dowiązanie w brew literą “g”, więc na przykład, aby wykonać /usr/local/bin z wersją brew, użyj ls. Po prostu wykonaj gls w ls -l i poszukaj połączonych plików - to są te, które /usr/local/bin tam umieścił. Uwaga: Zainstalowane w brew narzędzia, które muszą być dostępne pod ich prawdziwymi nazwami, znajdują się w brew.

Nie umieszczam /usr/local/Cellar/coreutils/8.21/libexec/gnubin w mojej ścieżce z dwóch powodów - te powody są na dole mojej odpowiedzi.

Aby ocenić kolizje nazw w twoim systemie, użyj /usr/local/bin i poszukaj tej sekcji - Oto interesujące wyjście 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

Powodem, dla którego nie umieszczam narzędzi brew doctor na pierwszym miejscu, w rzeczywistości wcale, jest to, że polecenia brew zainstalowane brew i ls nie obsługują poprawnie ACL systemu plików, w rzeczywistości, ostatnim razem, gdy sprawdzałem (co było w zeszłym tygodniu), nie były one obsługiwane w ogóle. Jest to poważny problem, i aby go uniknąć, wraz z powiązanym problemem konfiguracji strony tar, który wiąże się z prawidłowym ustawieniem man, upewniam się, że najpierw umieszczam narzędzia związane z $PATH, zwłaszcza te, które można znaleźć w OSX i /bin.

Innym powodem, dla którego w ogóle nie umieszczam /usr/bin w mojej ścieżce jest to, że /usr/local/bin nie gra dobrze z innymi, a brew i fink (MacPorts) mają o wiele więcej obsługiwanych pakietów obecnie, których potrzebuję NOW. Na przykład, mogę uzyskać port z gnome-terminal, ale byłoby to dużym wysiłkiem, aby skonstruować formułę i zrobić to samo z fink. Tak więc, trzymam brew i /sw w moim wyszukiwaniu /opt (odpowiednio dla $PATH i fink) i odwołuję się do rzeczy, których potrzebuję z port, w tym /usr/local/bin, albo przeliterowane, albo używam gnat bash‘s, albo źródłowo plik alias dla zupełnie innego środowiska, gdy piszę kod setup.

Rzecz w tym, że to naprawdę zależy od tego, czego chcesz i potrzebujesz w danym momencie.

Oto przykład problemu z ACL, o którym wspomniałem powyżej.

Z użyciem standardowych narzędzi Ada:

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

oraz z zainstalowanymi narzędziami OSX:

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

oraz

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

Uzyskasz podobne wyniki z brew i nie znam wielu innych narzędzi tar, ale kto może sobie pozwolić na to, aby coś się zepsuło 6 miesięcy później z powodu problemu brew!

4
4
4
2014-09-18 20:46:55 +0000

Jest tu cała masa dobrych odpowiedzi. Oto moja:

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

Oszczędza ci konieczności tworzenia osobnego aliasu dla każdego programu, a jako bonus pozostawia domyślne instalacje dostępne na wypadek, gdybyś ich potrzebował.

Działa tak samo, jeśli używasz ZSH; po prostu zamień bashrc na zshrc. Możesz zamienić my na _ lub nawet @, aby zaoszczędzić na pisaniu.

2
2
2
2013-07-30 18:47:40 +0000

Zamiast mieszać w PATH w ogóle (co w mojej historii wraca, aby spalić mnie miesiące później) dodałem alias dla git w moim katalogu aliasów zsh (~/.zshrc/custom/git_alias.zsh).

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

0
0
0
2017-05-23 17:29:13 +0000

Możesz wydać następującą komendę w terminalu, doda ona katalog domowy brew + /bin w PATH twojego dowolnego pliku inicjującego SHELL “rc” (bash, zsh, csh)

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

Enjoy !

0
0
0
2014-03-21 11:54:36 +0000

Wolę ograniczyć zmiany w zmiennych środowiskowych takich jak $PATH do użytkowników, którzy rzeczywiście chcą tej zmiany. Tak więc, po prostu dodaję poniższe do ~/.bashrc:

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