Open rheaplex opened 11 years ago
In plain Rails 3.2, without rbenv, I notice that rinari-web-server does the same thing - runs an executable script as ruby - but in that case it is harmless as without the shim, 'rails' is indeed a hashbang ruby script. (It bypasses the 'rails' script in the gem path, and directly uses the one in the app. I think there is a little duplication of Rails ruby code in elisp to achieve this.)
-*- mode: ruby-compilation; default-directory: "/home/david1/LocalSupport-dcorking/" -*-
RubyComp started at Wed Jul 31 12:33:39
ruby /home/david1/LocalSupport-dcorking/script/rails server
Would it be safe to fix rinari-web-server to fork a shell command instead of a ruby script, or is it important in other ways that rinari finds a real ruby script on that path?
@robmyers Which rinari package do you have? The Marmalade package is currently very outdated, so if you've got that one, you should perhaps try the MELPA package instead.
@dcorking If the shebang line in RAILS_ROOT/script/rails
is #!/usr/bin/env ruby
, as it always should be, then there should be no difference. Or am I missing your point?
@purcell - thanks for explanation.
I've worked around this with a naive modification of the `rinari--rails-path' function:
(defun rinari--rails-path ()
"Return the path of the 'rails' command, or nil if not found."
(if 'rbenv--initialized
(rbenv--call-process "which" "rails")
(let* (script (rinari-script-path))
rails-script (((expand-file-name "rails" script)))
(if (file-exists-p rails-script)
rails-script
(executable-find "rails")))))
Basically, we first check to see if rbenv is in use, and if it is, ask rbenv what it thinks is the canonical path to our rails script. It works here, but doubtless needs work to catch all edge-cases.
I'm using emacs 24.3.1, with the current rinari from MELPA (20130721.1241)
@dbye I'm also using rbenv, and this all works fine for me without any extra code, so I'm really not sure what problem you're working around. If someone could explain that to me so that I can reproduce it locally, I'm happy to make any necessary changes to rinari
.
-Steve
It's the melpa version, I chose it as it had a more up-to-date looking name. :-)
In Rails 4.0 there isn't a script subdirectory in the project root. There is a bin/rails subdirectory in the project root, and that is a ruby script with its first line set to #!/usr/bin/env ruby . But that isn't called, the .rbenv shim is called instead because that is the rails that rinari finds. Since that is a Bash script it doesn't run when called with the Ruby interpreter.
Thanks, that should help me track things down: watch this space! (Overall, the MELPA rinari is much better than any another available package.)
Okay, so I committed a different workaround to yours, which doesn't require that rinari
knows anything about rbenv
. In short, if you've got a RAILS_ROOT/bin/rails
, it will use that before falling back to searching $PATH
. Please let me know if you have any further issues.
@purcell - @robmyers beat me to it. The new implementation of rinari--rails-path now correctly returns the ruby script instead of the rbenv shim, so my rails server starts. Thanks!
I've installed Ruby 2.0.0-p247 and Rails 4.0 via rbenv and gem. I've installed rinari through package-install in Emacs 24.3.50.1.
When I run M-x rinari-web-server I get the following error:
ruby /home/blah/.rbenv/shims/rails server ruby: no Ruby script found in input (LoadError)
When I open ~/.rbenv/shims/rails it is a Bash script with execute permission set, so ruby is right. :-)
If I add the following hideous hack to my .emacs file then M-x rinari-web-server works:
(defun rinari--rails-path () "/home/blah/.rbenv/versions/2.0.0-p247/bin/rails")
I've read through the code and it looks like the Bash script being executable but not a Ruby file is the problem. Is there a better way of configuring my environment or rinari to handle this, or have I got something badly wrong in my setup?
Thank you.