Emacs i wiersze poleceń $ PATH nieporozumienia w OSX

Problemy z PATHustawieniami Emacsa, które wpływają na moje środowisko Haskell:

Korzystam z ZSH, a kiedy idę do linii poleceń i dzwonię echo $PATH, zwraca:/Users/g/Library/Haskell/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin

Pochodzi z .zprofilekonfiguracji, w której mam:

# Set the list of directories that Zsh searches for programs.
path=(
  ~/Library/Haskell/bin
  /usr/local/{bin,sbin}
  $path
)

Tak więc z linii poleceń, kiedy dzwonię which cabal, poprawnie otrzymuję:/Users/g/Library/Haskell/bin/cabal

Kiedy uruchamiam Emacsa i przechodzę do shelli dzwonię which cabal, dostaję: /usr/bin/cabalco powoduje problem, ponieważ jest to inna wersja.

Kiedy sprawdzam echo $PATHz Emacsa shell, widzę:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/g/Library/Haskell/bin:/usr/local/sbin

Nie mam pojęcia, jak, u licha, PATHmoże być inaczej ...

Czy ktoś wie, jak sprawić, by mój ZSHshell i Emacs zgodzili się na to samo PATH? Podejrzewam, że to właśnie kontroluje, skąd cabaljest ładowany.

AKTUALIZACJA : Uruchamianie echo $SHELLz wydruków Emacsa:/bin/zsh

AKTUALIZACJA 2 : To jest na OSX .

AKTUALIZACJA 3 : Próbowałem użyć modułu exec-path-from-shell i nie działa. Nadal mam te same problemy, a efektem ubocznym jest popsucie kolorów terminalu:

AKTUALIZACJA 4 : Zainstalowałem Emacsa przez brew install --cocoa --srgb emacsi uruchamiam emacsa, który jest połączony w ten sposób:

~ ❯❯❯ which emacs
/usr/local/bin/emacs
~ ❯❯❯ l /usr/local/bin/emacs
lrwxr-xr-x  1 g  admin    30B 29 Jan 18:34 /usr/local/bin/emacs -> ../Cellar/emacs/24.4/bin/emacs
~ ❯❯❯ l /usr/local/Cellar/emacs/24.4/bin/emacs
-r-xr-xr-x  1 g  admin    87B 29 Jan 18:34 /usr/local/Cellar/emacs/24.4/bin/emacs

Możesz także zainstalować pakiet exec-path-from-shell i dodać go do pliku init:

(exec-path-from-shell-initialize)

Jest to irytujący problem środowiskowy OSX, $PATHpojawienie się w Emacsie pochodzi z /etc/pathspliku, który następnie dołącza się do wszystkiego, co ustawiłem w powłoce. Dodałem /Users/g/Library/Haskell/binna początku /etc/pathspliku, a następnie działał dobrze.

Przechodzenie do powłoki i wywoływanie echo $PATHEmacsa pokazuje teraz:/Users/g/Library/Haskell/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/sbin

I cabal„s wersja jest rzeczywiście cabal-install version 1.22.2.0: D

Dziękuje wszystkim!!

Jeśli uruchomisz emacsa ze swojego środowiska GUI (gnome, kde, ...), twoje skrypty startowe nie będą pozyskiwane z twojego środowiska. Więc to $PATH, co dokładnie ustawiłeś .zsh, nie zostanie załadowane. Środowiska GUI nie generują ich na ogół, chociaż mogą załadować ~/.profileplik.

Możesz spróbować dodać to do .pam_environment:

PATH DEFAULT=${PATH}:/MYHOMEDIR/Library/Haskell/bin:/usr/local/bin:/usr/local/sbin

Musisz ponownie uruchomić sesję GUI, aby ją załadować.

Ten dokument może pomóc w $PATHprawidłowym ustawieniu zmiennej:

https://help.ubuntu.com/community/EnvironmentVariables#Session-wide_environment_variables

Używam tego ~/.pam_environmentpliku do zarządzania zmiennymi środowiskowymi, które muszą być dostępne z procesów powłoki lub emacsa.

PS: Zręczny komentator wskazuje, że prawdopodobnie korzystasz z komputera Mac. Nie wiem, jak skonfigurować $PATHinterfejs GUI na komputerze Mac, ale nadal pozostaje kwestia różnicy między środowiskiem powłoki a środowiskiem GUI. Sposób konfiguracji $PATHGUI wydaje się zależeć od wersji systemu operacyjnego. Możesz jednak użyć:

(setenv "PATH" (concat (getenv "PATH") ":/foo/bar"))

W twojej ~/.emacs.d/initjeśli chcesz tylko rozwiązanie, które powinno działać.

PPS: Jeśli chcesz uruchomić powłokę w emacsie, prawdopodobnie lepiej jest użyć ansi-termzamiast shell.

Jeśli jakaś część ŚCIEŻKI zostanie zgubiona, możesz dodać ją do ~ / .emacs

;;; We add /path/to/something/extra by appending it to the path
(setenv "PATH" (concat (getenv "PATH") ":/path/to/something/extra"))
;;; /path/to/something/extra is now at the end of the PATH.
;;; or you can use:
;(setenv "PATH" (concat "/path/to/something/extra:" (getenv "PATH")))
;;; /path/to/something/extra is now at the beginning of the PATH.

Aby uniknąć problemów ze ŚCIEŻKĄ, zawsze uruchamiam emacsa z wiersza poleceń z ŚCIEŻKĄ wyeksportowaną z ~ / .bashrc.

Innym sposobem na osiągnięcie tego jest po prostu powiedzenie powłoce, że jest to powłoka logowania, aby pozyskała wszystkie właściwe pliki. Robię to dla bash, ustawiając explicit-bash-argsna ("--noediting" "--login"). Wygląda na to, że odpowiednikiem dla zsh byłoby ustawienie explicit-zsh-argsna ("-l").

Więc w moim .emacs:

(setq explicit-bash-args '("--noediting" "--login"))

W twoim coś takiego:

(setq explicit-zsh-args '("-l"))

Myślę, że "--noediting"jest to niepotrzebne i wydaje się, że nie ma sposobu, aby powiedzieć o tym Zsh, ale może to być coś do zbadania, jeśli to nie zadziała tak, jak można oczekiwać.

Możesz również ustawić domyślną ścieżkę dla całego systemu OS X, na przykład zapisując listę właściwości w następujący sposób ~/Library/LaunchAgents/my.startup.plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>my.startup</string>
  <key>ProgramArguments</key>
  <array>
    <string>sh</string>
    <string>-c</string>
    <string>launchctl setenv PATH /usr/local/bin:/usr/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin</string>
  </array>
  <key>RunAtLoad</key>
  <true/>
</dict>
</plist>

Nowa ścieżka powinna zostać pokazana w powłokach, Emacsie i innych aplikacjach po wylogowaniu i ponownym zalogowaniu.

Ta metoda nie zmienia ścieżki w aplikacjach, które są otwierane jako elementy logowania lub gdy aplikacje są ponownie otwierane podczas logowania po wymuszonym wyłączeniu. Jeśli masz Emacsa, aplikację terminalową lub inne aplikacje, w których chcesz zmienić ścieżkę w elementach logowania, musisz je usunąć.

W wersji 10.9 i wcześniejszych możesz również dodać taką linię do /etc/launchd.conf:

setenv PATH /usr/local/bin:/usr/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin

Jednak wsparcie dla /etc/launchd.confzostało usunięte w 10.10.