I guess what this bug is best described as: 'exec-path-from-shell-printf fails when zsh interactive shells auto-start tmux' discussion #12 This is because $TMUX is set, so the zprezto tmux module assumes you're already in tmux and doesn't start it again.) discussion #11 (Note: What threw me for a loop was that when I launching 'open -a Emacs' from within a tmux/zsh environment, Emacs started up just fine. However, possibly because this is emacs, it fails with a "open terminal failed: not a terminal" zprezto can also do this via screen, and I believe that the other zsh package, oh-my-zsh, can be configured to do this as well.Įxec-path-from-shell-printf runs printf from an interactive shell, causing tmux to start. Zprezto can be configured to, on interactive shells, automatically run tmux and attach to an existing sesssion (or create a new one). It looks like zprezto is doing something to cause this function to return nil. When Emacs.app doesn't work, (exec-path-from-shell-printf "%s" (list ("$PATH" "$MANPATH"))) returns nil. when Emacs.app works, (exec-path-from-shell-printf "%s" (list ("$PATH" "$MANPATH"))) returns what looks like path values. ![]() The thing is, I can't reproduce the error even if I try to get the value of a non-existent env var, e.g. Feel free to close the issue if you feel the issue is on zprezto's end. I have workarounds for my purposes, but I'm not sure whether exec-path-from-shell should be expected to handle an undefined MANPATH. Yeppers, zprezto explicitly does not set a MANPATH environment variable, see. ![]() It was still giving me problems if I chsh'd my shell to /bin/zsh, which allowed me to isolate the cause to something zprezto is doing (since I have it installed.) Removing the zprezto-supplied zsh config files allows Emacs to work properly, so zprezto must be clearing the manpath or something. What's that zsh version you've got? I just use the Apple-installed zsh 5.0.2. I guess if the OS X (tm) way is by changing the shell in terminal and/or prefpane, I'll do that :) discussion #5 changing it back to /bin/bash stops the problem, and modifying my profile in terminal/iterm to launch zsh instead doesn't cause any problems either. But FWIW, I'm using zsh on 10.9 here, and I also don't see the error you reported. You should probably set your shell preference in the Users prefpane, so it's used by default everywhere. The weird thing is that when I set /usr/local/bin/zsh as my shell in terminal/iTerm, doing 'open -a Emacs' works, but when using /bin/bash w/ "open -a Emacs", that's when I get the error. Oh weird! It's actually "/usr/local/bin/zsh", which is my homebrew install of ZSH. What's the result of evaluating (getenv "SHELL") using M-: ? discussion #2 And plenty of people must have this configuration, so I think part of the story must be missing here. I can't reproduce this on OS X 10.9 with bash. *el$" "Loading Prelude's core." require prelude-packages prelude-ui prelude-core prelude-mode prelude-editor prelude-global-keybindings darwin prelude-osx "Loading Prelude's modules." expand-file-name "custom.el" "Prelude is ready to do thy bidding, Master %s!" prelude-eval-after-init run-at-time 5 nil prelude-tip-of-the-day prelude-modules-file prelude-personal-dir custom-file current-user] 6) I updated my packages via ELPA and MELPA, so I should have the tcsh-specific fix for this.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |