Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Calling exec-path-from-shell-initialize freezes Spacemacs on FreeBSD #33

Closed
cubranic opened this issue Nov 20, 2015 · 14 comments
Closed

Comments

@cubranic
Copy link

Running (exec-path-from-shell-initialize) on FreeBSD causes Spacemacs to freeze during startup (bug syl20bnr/spacemacs#3887). The started bash process seems to be stuck, running at 100% and never returning. The full arguments of the process according to ps www are:

/usr/local/bin/bash -l -i -c /usr/bin/printf '__RESULT\\000%s\\000%s' "${PATH-39a3b6c118441cd3550bf60cd83b0bba}" "${MANPATH-39a3b6c118441cd3550bf60cd83b0bba}"
@cubranic cubranic changed the title Loading exec-path-from-shell Calling exec-path-from-shell-initialize freezes Spacemacs on FreeBSD Nov 20, 2015
@purcell
Copy link
Owner

purcell commented Nov 20, 2015

This is almost certainly due to something odd in your .bashrc or other shell startup file which causes it to wait for input. Try temporarily removing those files to see if that helps.

@purcell
Copy link
Owner

purcell commented Nov 20, 2015

You can also add (setq exec-path-from-shell-debug t) to the start of your emacs config file to get extra info in the *Messages* buffer about what exec-path-from-shell is doing.

@cubranic
Copy link
Author

I was able to reproduce on a fresh install of PC-BSD 10.2. There were no files or customizations of mine just a:

chsh -s /usr/local/bin/bash
pkg install editors/emacs
git clone --recursive https://github.com/syl20bnr/spacemacs ~/.emacs.d
emacs

Setting exec-path-from-shell-debug, I get this line in `Messages:

Invoking shell /usr/local/bin/bash with args ("-l" "-i" "-c" "/usr/bin/printf '__RESULT\\000%s\\000%s' \"${PATH-ecaef263eeac4673e2f61547a7a043e3}\" \"${MANPATH-ecaef263eeac4673e2f61547a7a043e3}\"")

Removing shell configuration files from $HOME didn't change anything.

Running /usr/local/bin/bash -l -i -c "/usr/bin/printf '__RESULT\\000%s\\000%s' \"${PATH-ecaef263eeac4673e2f61547a7a043e3}\" \"${MANPATH-ecaef263eeac4673e2f61547a7a043e3}\"" from the terminal seems to works just fine, so I'm not sure what the problem is with Emacs.

Also, running this line with M-! (shell-command), I get the same hang on the Bash process. Experimenting a little deeper, the problem seems to be in the "-i" switch: even running /bin/echo hello hangs if "-i" is present. Adding "--noprofile --norc" does not help, so it's not the shell startup files but something deeper.

Finally, running Bash with M-& (async-shell-command) works fine. So, while the bug is either in Emacs or Bash itself, you could perhaps have a workaround to use something like that instead.

@purcell
Copy link
Owner

purcell commented Nov 20, 2015

It's definitely odd, but seems platform specific, since this package is widely used and this problem has never previously been reported.

You can omit the "-i" switch by setting exec-path-from-shell-arguments to simply '("-l") -- this would actually be the right default if everyone did the right thing with their shell startup files, but it prevents bash from reading ~/.bashrc, and I suspect I'd get a deluge of bug reports about exec-path-from-shell "not working" if I changed it.

@purcell
Copy link
Owner

purcell commented Nov 20, 2015

As a stepping stone to removing "-i" from the defaults at some future point, I've committed a change in 63a88bf which will detect whether users are (incorrectly) setting env vars in their shell's interactive startup file, and warn them if so.

@purcell
Copy link
Owner

purcell commented Nov 20, 2015

In the meantime, this doesn't seem to be an issue which I can fix directly by modifying exec-path-from-shell, so I'll close it, but feel free to discuss further here.

@cubranic
Copy link
Author

I filed an Emacs bug for this: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21972.

@purcell
Copy link
Owner

purcell commented Nov 21, 2015

Yeah, must be somehow related to a clash between Emacs' TTY or stdout/stdin setup for subprocesses and bash on that platform.

@rbarraud
Copy link

I have exactly the same problem on FreeBSD 10.1-RELEASE-p24 .
Any progress on any front yet?

@purcell
Copy link
Owner

purcell commented Dec 18, 2015

This isn't really an exec-path-from-shell issue, to be honest, as the filed emacs bug demonstrates. The workaround would be to (setq exec-path-from-shell-arguments '("-c")) before calling exec-path-from-shell-initialize etc.

@rbarraud
Copy link

True. Thanks for the fast reply. I suspect the fix may be to only invoke exec-path-from-shell on OS X - as it seems to be problematic on FreeBSD/PCSBD.

Is there any particular reason why you wouldn't integrate:

;; (when (memq window-system '(mac ns))
;; (exec-path-from-shell-initialize))
;;

(as suggested for 'other platforms' in the .el file) as the default? - Which other platforms actually need this?

Thanks Steve :-)

@cubranic
Copy link
Author

@rbarraud If you've run into this with Spacemacs, then ask them not to run it on non-Aqua platforms: syl20bnr/spacemacs#3887, or as a workaround just add exec-path-from-shell to the list of excluded packages in your .spacemacs.

@purcell
Copy link
Owner

purcell commented Dec 23, 2015

I've also heard from users that some Linux (and Windows?) set-ups require or benefit from exec-path-from-shell, so I'm not sure the solution is limiting it OS X. Seems like the ideal would be to exclude BSD for now.

@lf94
Copy link

lf94 commented May 17, 2016

Thank you @cubranic that suggestion worked perfectly. Reporting in from FreeBSD 10.3 using Emacs devel 25.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants