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

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?

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ź.

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.

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”

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.

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!

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.

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'

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"

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ę !