ruby-compilation using wrong ruby version

[littlemove]

First, I'm pretty sure this has to be with some of my config because nobody is reporting it but it's driving me crazy so here it goes:

Environment description: OS: OSX 10.8.3. Emacs version 24.3.50.1. Rinari is installed via el-get. I use rbenv to manage ruby versions, but mostly I used the global version which is set to 1.9.3-p392. I've setup Emacs exec-path to "/Users/diego/.rbenv/shims" "/Users/diego/.rbenv/bin" "/usr/local/bin" "/usr/local/sbin" "/bin" "/sbin" "/usr/bin" "/usr/sbin" "/opt/local/bin" "/opt/local/sbin" so rbenv shims and ruby versions should take precedence over the default ruby installation that comes with OSX. I use bundler to manage gems.

Problem: When I tried to start a rails webserver via rinari-webserver I get an error

-*- mode: ruby-compilation; default-directory: "~/Documents/workspaces/rails3-project/" -*-
RubyComp started at Mon May 13 12:38:12

ruby /Users/diego/Documents/workspaces/rails3-project/script/rails server
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require': no such file to load -- bundler/setup (LoadError)
    from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `require'
    from /Users/diego/Documents/workspaces/rails3-project/config/boot.rb:6
    from /Users/diego/Documents/workspaces/rails3-project/script/rails:5:in `require'
    from /Users/diego/Documents/workspaces/rails3-project/script/rails:5

RubyComp exited abnormally with code 1 at Mon May 13 12:38:13

Same goes for rinari-rake. But rinari-console works just fine.

So it seems ruby-compilation ignores my exec-path and goes looking for the default OSX installation.

Thank you for taking time reading this and for your awesome work in Rinari.

[purcell]

I have a similar setup locally, and it works for me.

This looks like a path problem on your side. It is usually not sufficient to set exec-path: you also need to set the PATH environment variable. This is a particular problem on OS X, and the reason why I published an elisp library called exec-path-from-shell. Please give that library a try, and let me know if it helps.

-Steve

[dgutov]

Shouldn't rbenv.el take care of that?

[purcell]

Maybe, but the thing I like about rbenv is that it requires less magic than rvm -- just getting the path right is enough. I personally didn't see the point of rbenv.el.

[littlemove]

I was doing that via some custom code (which I probably stole from you at some point)

(setenv "SHELL" "/usr/local/bin/zsh")
(setenv "ESHELL" "/usr/local/bin/zsh")

(defun set-exec-path-from-shell-PATH ()
  (interactive)
  (let ((path-from-shell (replace-regexp-in-string "[ \t\n]*$" "" (shell-command-to-string "$SHELL --login -i -c 'echo $PATH'"))))
    (setenv "PATH" path-from-shell)
    (setq exec-path (split-string path-from-shell path-separator))))

(when (and *is-a-mac* window-system)
  (set-exec-path-from-shell-PATH))

(provide 'exec-path)

and (getenv PATH) gives the same string as exec-path.

Anyway, I will try your library and let you know the results.

[littlemove]

Thanks for your patience.

I replace the code above with your library with no success. Bear in mind that the values returned by (getenv PATH) and exec-path were the same I got with "my" code.

I've got the same config working on another computer with no problem... so it's obviously something on my side but, how come ruby-console or shell are using the right path?

[purcell]

Okay, so in the output you pasted originally, the command

ruby /Users/diego/Documents/workspaces/rails3-project/script/rails server

did not work properly, because the selected ruby was obviously the system-wide OS X ruby under /System/Library/Frameworks.

The console command works for you. Well, when the console command is run, a subshell is not started, i.e. emacs directly runs the console command as a sub-process.

In contrast, the commands which are failing for you are run inside a sub-shell, because they are run via the "compile" machinery. That code, in turn, uses the shell-file-name variable to determine which sub-shell to pass the command to.

Now, shell-file-name is initialized to (getenv "SHELL") at startup, so the problem appears to be that you've subsequently overridden your SHELL env var, but Emacs is still running subprocesses with a different shell (probably /bin/bash) which doesn't have the rbenv magic set up. You can confirm that by inspecting the value of shell-file-name.

One solution would therefore be to (setq shell-file-name (getenv "SHELL")).

But what you might want to do instead is to use chsh to properly change your default user shell. I use the Apple-installed zsh myself, and have never encountered this issue.

[littlemove]

Both shell-file-name and SHELL got the same value /usr/local/bin/zshwhich is correct and my shell it's properly configured as well.

I'll keep trying to figure this out.

[purcell]

Perhaps try using M-x compile to run /usr/bin/env, and see if there are any clues about what the sub-shell environment is actually like.

[littlemove]

Ok, inside emacs env returns a PATH with /usr/bin prior on PATH to the rbenv shims: PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/Users/diego/.rbenv/shims:/Users/diego/.rbenv/bin:/usr/local/sbin:/opt/local/bin:/opt/local/sbin

[purcell]

I still think it's running the wrong shell. :-)

Try M-x compile then pstree -p $$: from the output, you should be able to see what shell is executing pstree. (I've just tried it using the pstree from homebrew)

[purcell]

(Sorry: just use "pstree" as the command.)

[littlemove]

I didn't have / know about pstree command :). Anyway, trying to compile that I've got emacs telling me zsh:1: command not found: pstree

Next I installed pstree. Run again. pstree process has 76545 diego /Applications/Emacs.app/Contents/MacOS/Emacs -psn_0_20071203as parent.

Question: ¿How come (getenv PATH) and M-x compile /usr/bin/env got different values?

[purcell]

(getenv "PATH") returns the path that Emacs sees. When compile runs a command, it uses that PATH to execute a shell for running the command, and the shell parses its start-up files, which may then change the PATH seen by the command.

You noticed that /usr/bin:/bin:/usr/sbin:/sbin: is getting added to the PATH. I expect that one of your shell start-up scripts is responsible for that, so you might get a clue by looking in ~/.profile, ~/.bash_profile, ~/.bashrc, ~/.zshenv, and ~/.zshrc.

[littlemove]

Finally!

It's not in my profile config, it's on the system wide configuration of zsh on /etc/zshenv

Inside, it calls /usr/libexec/path_helper which mess with the PATH. Why is this file (/etc/zshenv) executed instead or after my own zsh config file when emacs runs a subshell it'e beyond me.

Thank you so much. You've been more than patient knowing that the problem was obviously on my config.

[purcell]

No problem. I'm happy you tracked it down and solved the issue. :-)

Have a great day!