Incompatability with bash session saving in OS X El Capitan

[ghost]

I have noticed that when using emacs with spacemacs my MANPATH variable (which I have not set) is set to a garbage string.

97e625ce3d2a2db7f21b445e5a217d32Saving session...^[[?1034hcompleted.

I have traced this bug to exec-path-from-shell library. In particular in the function exec-path-from-shell-getenvs there is a test performed to determine if an environment variable is set (on lines 168--169):

(unless (string-equal random-default value)
    value))

This test produces a false positive for MANPATH, as it is comparing random-default to value which is equal to random-default with Saving session...^[[?1034hcompleted. concatenated onto the end. This Saving session...^[[?1034hcompleted. message was introduced in El Capitan and is specific to some sort of "session saving" for bash.

One quick fix is to replace lines 168--169 with:

(unless (string-prefix-p random-default value)
    value))

However, if possible it would be better to use a more robust method to check if a variable is set.

[purcell]

The problem is ultimately that your shell is printing spurious output, so there's no way for exec-path-from-shell to distinguish what it was trying to print from what the shell decided to print. I don't feel like your workaround is going to fix that in the general case, so I'm wary of adding it.

Probably removing "-i" from exec-path-from-shell-arguments (which I might do by default sometime: see #17 and #40) would help in this case, or it looks like (setenv "TERM_PROGRAM" nil) before invoking exec-path-from-shell would also work.

[ghost]

I would not recommend implementing my workaround!

Personally, I would say there are some fundamental problems with how you are getting environment variables. There is no need for this hacky random number trick you are using. A more robust solution could simply parse the output of printenv or declare.

Also, you can avoid the "spurious output" by printing to a stream other than stdout.

I would implement this myself, but I do not see myself using emacs much in the future.

In any event, thanks for writing the library!

[purcell]

Personally, I would say there are some fundamental problems with how you are getting environment variables. There is no need for this hacky random number trick you are using. A more robust solution could simply parse the output of printenv or declare.

I'd love to find a better solution -- the current one was obviously not the starting point, but has gradually arisen from the following constraints:

• Work with a number of different shells, including non-POSIX (fish)
• Distinguish empty values from unset values (that's the specific reason for the random value here)
• Handle arbitrary characters in env vars, with NUL being the only exception
• Require only one shell invocation in order to collect the values of multiple env vars, since each is expensive

Also, you can avoid the "spurious output" by printing to a stream other than stdout.

Oh, nice: I guess there might actually be a way to blackhole the spurious output, with some redirection magic.

I would implement this myself, but I do not see myself using emacs much in the future.

Fair enough, but you should really consider it! ;-) What editor/IDE have you come from? Spacemacs is quite a beast, so not necessarily the best entry into Emacs.

[ghost]

I found a better fix! Well it is better in my opinion...

Users of bash in OS X can turn off session saving by adding the file ~/.bash_sessions_disable. This will also disable the printing out the extra output message.

To answer your other questions: I am typically a vim user, but wanted to give spacemacs a try as it seems to be the new hotness. However, I may take your advice and simply try emacs with just evil.

[purcell]

Users of bash in OS X can turn off session saving by adding the file ~/.bash_sessions_disable. This will also disable the printing out the extra output message.

Ah, good tip!

However, I may take your advice and simply try emacs with just evil.

I came from Vim around 2000, and used Emacs with the built-in viper-mode for another 10 years... It's a bit more basic than evil, but solid and you can easily bolt on some extras. After that I switched to the native emacs bindings, but can still use vim easily enough.

[bradyt]

Hmm, this seems like a collision between OS X/MacOS 10.10+ and exec-path-from-shell, regarding the ~/.bash_sessions/ vs touch ~/.bash_sessions_disable. I'lll try the various strategies to remove error messages, come back to edit if I find notice anything significant.

[timhillgit]

This issue bit me as well, so I thought I'd take a stab at it. I looked at potentially using shell-command-to-string but the quickest fix was just to add a sentinel value at the end of the printf to designate the end of the output we're interested in. I've tested it on my own setup and it seems to get the job done. Thoughts?

[purcell]

That seems uncontroversial, @timhillgit - want to open a pull request so I can easily apply your commit?