Jak ustawić zmienną PATH na komputerze Mac, aby znaleźć narzędzia zainstalowane w Hombrew?

86

Próbuję skonfigurować Homebrew na nowym komputerze Mac (na poprzednich komputerach Mac instalowałbym pakiety ze źródła).

Pierwszy pakiet, który próbowałem zainstalować, to Git:

$ brew install git

Instalacja przebiegła pomyślnie, ale which gitnadal pokazuje ten, /usr/bin/gitktóry przyszedł z Lionem (myślę?). I nie ten, /usr/local/bin/gitktóry właśnie został 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 widać, /usr/bindomyślnie do wcześniej /usr/local/binw$PATH

Więc jestem zmieszany! Myślałem, że celem HomeBrew (i czymś, co twórcy mogą się chwalić) było to, że nie musisz zadzierać ze $PATHzmienną!?!

Co więc zrobiłem źle?

Meltemi
źródło
Czy wcześniej bałaganiłeś swoją ścieżkę i być może ułożyłeś ją w niewłaściwej kolejności? Również nie jestem pewien, dlaczego jest to „punkt chwalenia się” z homebrew ... nie podoba się koncepcja ścieżki lub modyfikacja jest złożoną rzeczą, która polega na pisaniu i zraszaniu 10 różnych list w twoim systemie ze specjalnymi uprawnieniami lub coś takiego ... ..
prodigitalson
1
ścieżka, a więc ta część, która nie jest związana z RVM, powinna być standardowym problemem. I nie, nie narzekam na konieczność zmiany ścieżki. Po prostu zdają się powtarzać twierdzenie, If you choose /usr/local, everything 'just works!'że muszę się zastanawiać, czego mi brakuje ... ponieważ to nie „po prostu działa”.
Meltemi

Odpowiedzi:

78

Uważam, że ten powiązany post był bardzo pomocny. Zamiast zmieniać $PATHzmienną, wystarczy po prostu edytować /etc/pathsplik.

Homebrew chce, żebym zmienił moją ŚCIEŻKĘ; nie mam pojęcia jak

Gdy tylko postąpiłem zgodnie ze wskazówkami i podałem /usr/local/binwyżej /usr/bin, moje problemy zostały rozwiązane.

  1. W systemie OS X otwórz Terminal
  2. Wpisz polecenie: sudo vi /etc/paths
  3. Wprowadź hasło, jeśli zostaniesz o to poproszony
  4. Zobaczysz listę ścieżek. Edytuj je, aby /usr/local/binścieżka była wprowadzana nad /usr/binścieżką
  5. *Zapisz i wyjdź
  6. Uruchom ponownie terminal

Oto jak wygląda moja po tym, jak to zrobiłem:

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

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

Możesz także otworzyć /etc/pathsplik w graficznym edytorze tekstu i edytować go w ten sposób.

Podziękowania dla fengda w Stack Overflow za jego odpowiedź.

jthomas
źródło
W przypadku dim dimów vi (takich jak ja) użyj d, aby wyciąć linię ip, aby wkleić ją w trybie poleceń
Gerard
10
Chciałbym zachować przy tym ostrożność - lepszą odpowiedzią jest po prostu zmiana ścieżki w .profile / .bash_profile i wyeksportowanie jej tam. Zmieniając / etc / paths, (potencjalnie) wpływasz na wszystkie procesy systemowe; zmiana PATH w .profile / .bash_profile lokalizuje preferencje zarówno dla twojego konta, jak i tych poleceń wywoływanych przez powłokę poleceń (która, w moim przypadku dla rozwoju, jest tym, czego chcę). Jeśli jesteś naprawdę ostrożny, możesz zrobić to, co sugeruje @Aristotle Pagaltzis w odpowiedzi poniżej.
rholmes
1
Czy jest jakiś moment, kiedy przestajesz myśleć, że jest coś strasznie złego, że prosta instalacja z menedżera pakietów zaprojektowanego dla OSX kończy się niepowodzeniem po wyjęciu z pudełka? Zmiana ścieżki jest potencjalnie zepsutą „poprawką” i BTW, dlatego natknąłem się na tę proponowaną poprawkę, ponieważ brew również nie aktualizuje mojej ścieżki, ale „ścieżki” są już w prawidłowej kolejności. Kolejny ślepy zaułek. Zatrzymaj szaleństwo, napraw pierwotną przyczynę.
Rick O'Shea,
Jest też path_helperi /etc/paths.d.
Simon Wright,
29

Ta odpowiedź jest nieaktualna. Preferowane PATHporządkowanie Homebrew było takie, jak wyjaśniono, ale nie jest to już prawdą. Jednak podejście to ma bardziej ogólne zastosowanie, więc ze względu na zainteresowanie, pozostawiam to.


Nie powinieneś

Homebrew celowo utrzymuje /usr/local/bin po /usr/bin w ścieżce dla maksymalnej kompatybilności. Odwrócenie kolejności tych katalogów PATHpoprzez edycję /etc/pathsoznaczałoby, że wszystkie programy w dowolnym miejscu w systemie, bez względu na to, jak zostały uruchomione, otrzymają wersję polecenia Homebrew. Ale niektórzy mogą spodziewać się wersji Apple lub po prostu nie będą mogli korzystać z nowszej wersji itp.

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

W szczególności częścią moich zwyczajów związanych z Uniksem jest posiadanie ~/binkatalogu, który umieszczam na początku PATH. To jeden z pierwszych bitów w moim .bashrc:

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

Sprawdza, czy PATHzawiera ~/bin, a jeśli nie, dodaje. Po wprowadzeniu tego, wybiórcze sprawianie, aby tylko zarządzane przez Homebrew gitmiało pierwszeństwo przed wersją systemową (zamiast każdego pliku binarnego zarządzanego przez Homebrew) i tylko dla twoich sesji powłoki (zamiast wszystkich programów uruchamianych z dowolnego miejsca, w tym programów GUI), jest tak proste jak symlinkowanie:

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

Państwo mogłoby podlinkowujemy /usr/local/Cellar/git/1.8.2.1/bin/gitbezpośrednio, ale wtedy trzeba by naprawić dowiązanie za każdym razem robił brew upgrade git(bezpośrednio lub pośrednio). Łącząc się z dowiązaniem symbolicznym Homebrew o stałej lokalizacji, nie musisz się tym martwić.

Więc dodajesz katalog do swojego $HOME, abyś mógł dodać swój własny PATH, abyś mógł dowiązać symbolicznie do dowiązania symbolicznego, a to rozwiązuje twój problem i wywołuje uśmiech na Dr Seussie. Yo dawg Stado, które lubisz dowiązania symboliczne, więc umieszczamy ścieżkę PATH, abyś mógł dowiązać symbolicznie podczas symlinkowania.

Arystoteles Pagaltzis
źródło
1
Doskonale, to odpowiada dokładnie na to, co się zastanawiałem!
N_A,
Wydaje się, że SEEMS to właściwa odpowiedź, ale nie mogę znaleźć dokładnych poleceń do uruchomienia. Podczas tworzenia dowiązań symbolicznych ciągle pojawia się komunikat „Plik istnieje”.
Ryan
Przepraszam, za mało szczegółów, żeby ci pomóc.
Arystoteles Pagaltzis
1
@ Ryan upewnij się, że masz porządek argumentów bezpośrednio w lnpoleceniu. Pierwsza ścieżka to cel, a druga to dowiązanie symboliczne
Freedom_Ben
1
to prawda, że ​​na el cap nie udało mi się uzyskać przestarzałej odpowiedzi i udało mi się (używam ZSH) edytowanie kolejności ścieżki w .zshrcexport PATH="/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin"
Urs
17

Nie zrobiłeś nic złego, ale wydaje się całkiem jasne, że gdybyś znalazł się /usr/local/binna swojej drodze, zanim /usr/binten konkretny problem zniknie. Najłatwiej jest to zrobić i umieścić coś takiego

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

w twoim, ~/.bash_profilewięc wszystko, co instaluje Homebrew, znajduje się jako pierwsze. W ten sposób skonfigurowałem to na moim Macu i działało to dla mnie tak długo, jednak YMMV.

Wygląda na to, że wierzą, że przydałoby się /usr/local/binto później /usr/bin , więc chociaż mogłem zepsuć własne $PATH, widzę, gdzie brakuje ich dokumentacji:

Pamiętaj, że powinieneś /usr/local/binpo to wstawić, /usr/bin ponieważ niektóre programy będą oczekiwać, że dostaną wersję systemową, np. Ruby, i zepsują się, jeśli otrzymają nowszą wersję Homebrew.

Z rozbieżności między wiki a piwnym lekarzem # 10738 . Należy zauważyć, że dokument ten mówi dalej, „FAQ (powyższy cytat) odnosi się do PATH ustawienie dla aplikacji GUI; lekarz (rada umieścić /usr/local/binna przodzie /usr/bin . W PATH) odnosi się do PATH ustawienie dla aplikacji CLI”

Nick Klauer
źródło
1
Czy to nie pozostawi mi dwóch /usr/local/bins $PATH? Tak mi się wydaje. Zastanawiam się, czy zamiast tego powinniśmy edytować kolejność domyślnych ścieżek /etc/pathslub zawartość /etc/paths.d? Ale to wpłynie na każdego użytkownika ... może nie jest zła rzecz. W każdym razie chciałem tylko zobaczyć, jak podeszli do tego inni ludzie.
Meltemi
@Meltemi, duch tej odpowiedzi jest poprawny: zaktualizuj swój PATH(zgodnie z własnym wyborem), aby go /usr/local/binpoprzedzić /usr/bin. Ja osobiście zaktualizować PATHin .bash_profilejak sugeruje tutaj.
@ Nick - ciekawe informacje ... i służy tylko do pomieszania spraw (przynajmniej moich spraw) ... Dokumenty Homebrew wydają się sugerować, że polecenia terminalu powinny pobierać aplikacje, /usr/local/binnawet jeśli ślada /usr/binna ścieżce. Ale aplikacje GUI wymagają specjalnego kodowania? Wygląda na to, że wszystkie aplikacje, z graficznym interfejsem użytkownika lub nie, wymagają zmiany zmiennej $ PATH. Czego więc brakuje mi (lub twórcom Homebrew)?
Meltemi
Myślę, że Homebrew zakłada, że ​​chcesz najpierw użyć pliku wykonywalnego dostarczonego przez Apple - git jest zmianą, ponieważ dopóki Lion nie został dostarczony przez Apple, więc Homebrew go potrzebował - teraz możesz użyć Apple,
użytkownik151019
Zgadzam się z Markiem w tej sprawie. W przypadku MacPorts i Fink założeniem było zapewnienie całkowicie nieskazitelnego, oddzielnego środowiska od wszystkiego, co Apple dostarczał po wyjęciu z pudełka. Homebrew uznał, że rzeczy Apple są świetne i nie należy ich unikać (po co pobierać inną wersję gcc, skoro Apple prawdopodobnie to zrobi?).
Nick Klauer
6

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

# Dodaj aplikację homebrew do PATH
eksport PATH = / path / to / homebrew / app / bin: $ PATH

Następnie załaduj ponownie bash lub source ~/.bashrc, i jesteś gotowy. Ponieważ ścieżka homebrew jest ważniejsza niż cokolwiek innego, bash załaduje wersję pobraną za pomocą homebrew.

Nathan
źródło
W OS X .bashrcnie jest domyślnie ładowany. Czy to robisz ręcznie?
slhck 18.04.13
O tak. Pochodzę z systemu OS X z Ubuntu i przyzwyczaiłem się do posiadania, .bashrcwięc czerpię go z mojego .bash_profile. Jeśli nie chcesz tworzyć pliku rc, możesz dodać polecenie do swojego .bash_profile.
Nathan
5

Jak rozumiem, brewnie umieszcza niczego, /usr/local/binco koliduje (ma taką samą nazwę jak) dystrybuowany plik wykonywalny Apple. Dlatego posiadanie /usr/local/binna ścieżce przed /bini /usr/binnie powinno być problemem, ponieważ nie powinno być kolizji nazw. * Jednak zobacz problemy z lsi taroraz za pomocą innych agregatorów pakietów, takich jak finki port(MacPorts), poniżej.

Brew robi jedną z dwóch znanych mi rzeczy, które pomagają zarządzać kolizjami nazw:

  1. Brewpozostawia niepowiązane beczki w piwnicy. Aby zainstalować rzeczy, brew pozostawia narzędzia tam, gdzie są i tworzy symboliczne linki do tych narzędzi /usr/local/bin. W przypadku narzędzi, które brewnie chcą kolizji nazw, nie tworzy dowiązania symbolicznego.
  2. Dla wielu, jeśli nie wszystkich standardowych narzędzi, które są również w /bini /usr/bin, brewprefiksy w link /usr/local/binz „g”, a więc na przykład, wykonują lsz wersją piwny, użytkowania gls. Wystarczy zrobić ls -lin /usr/local/bini szukać powiązanych plików - to te, brewumieszczone tam. Uwaga: brewZainstalowane narzędzia, do których należy uzyskać dostęp pod ich prawdziwymi nazwami, znajdują się w /usr/local/Cellar/coreutils/8.21/libexec/gnubin.

Nie stawiam /usr/local/binna swojej drodze z dwóch powodów - te powody leżą u podstaw mojej odpowiedzi.

Aby ocenić kolizje nazw w systemie, użyj brew doctori poszukaj tej sekcji - oto brew doctorinteresujące wyniki:

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 stawiam brewnarzędzi na pierwszym miejscu, w rzeczywistości wcale nie jest to, że brewzainstalowane lsi tarpolecenia nie obsługują poprawnie ACL systemu plików, w rzeczywistości, kiedy ostatnio sprawdzałem (który był w zeszłym tygodniu), nie były w ogóle załatwione . Jest to WIELKI problem i aby go całkowicie uniknąć, wraz z powiązanym manproblemem konfiguracji strony, który oznacza wraz z ustawieniem $PATHodpowiedniego, upewniam się, że umieściłem OSXpowiązane narzędzia, zwłaszcza te znalezione w, /bini /usr/bin, na początku.

Innym powodem, dla którego nawet nie postawiłem /usr/local/binna swojej drodze, jest to, że brewnie gra się dobrze z innymi, finka port(MacPorts) mają obecnie o wiele więcej obsługiwanych pakietów, których potrzebuję TERAZ . Na przykład mogę sobie gnome-terminalz tym poradzić fink, ale zbudowanie formuły i zrobienie tego samego byłoby dużym wysiłkiem brew. Więc trzymam /swi /optw moich poszukiwań $PATH(dla finki port, odpowiednio) i rzeczy referencyjne muszę z /usr/local/bintym gnat, albo sprecyzować, czy mogę użyć bash alias„S lub I source setupplik na zupełnie innym środowisku, kiedy pisanie Adakodu.

Chodzi o to, że tak naprawdę zależy od tego, czego chcesz i potrzebujesz w danym momencie.

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

Za pomocą standardowych OSXnarzędzi:

$ /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 brewzainstalowanymi narzędziami:

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

i

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

Uzyskasz podobne wyniki tari nie znam wielu innych brewnarzędzi, ale na kogo stać 6 miesięcy z powodu ACLproblemu!

Billy McCloskey
źródło
Dzięki za przydatne informacje. Jednak dla przypomnienia, teraz w moim systemie mam pliki wykonywalne o tej samej nazwie zarówno w / usr / bin, jak i / usr / local / bin (np. Git, który JEST symlinkowany, jak zauważasz). Tak więc domyślnie powodują konflikty. Chcę również zastąpić narzędzia systemowe do mojej pracy z powłoką.
rholmes
4

Jest tu mnóstwo dobrych odpowiedzi. To moje:

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 to konieczności tworzenia osobnego aliasu dla każdego programu i jako bonus pozostawia dostęp do domyślnych instalacji na wypadek, gdyby były potrzebne.

Działa tak samo, jeśli używasz ZSH; po prostu zamień się bashrcna zshrc. Można przełączać się myza _, a nawet @zaoszczędzić na pisanie.

Cheezmeister
źródło
2

Zamiast w ogóle zadzierać ze ŚCIEŻKĄ (która w mojej historii wraca by mnie spalić miesiące później) dodałem alias dla git w moim katalogu niestandardowych aliasów zsh (~ / .zshrc / custom / git_alias.zsh).

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

Jesse Smith
źródło
0

Wolę ograniczać zmiany do zmiennych środowiskowych, takich jak $PATHużytkownicy, którzy faktycznie chcą zmiany. Dlatego po prostu dodaję do ~/.bashrc:

export PATH="$(brew --prefix)/bin:$PATH"
Nils Werner
źródło
0

Możesz wydać następujące polecenie w terminalu, doda katalog domowy brew + + bin do ŚCIEŻKI twojego dowolnego pliku inicjującego SHELL „rc” (bash, zsh, csh)

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

Cieszyć się !

Vincedgy
źródło