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

[cubranic]

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}"

[purcell]

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]

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]

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]

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]

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]

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]

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

[purcell]

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

[rbarraud]

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

[purcell]

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]

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]

@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]

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.