eschulte/rinari

"apply: Spawning child process: invalid argument" error when run rinari-console in Windows emacs 24.

JamesYuan opened this issue · 17 comments

Run rinari-console in Windows emacs 24, the run command should be:

(run-ruby "d:/dev/scripts/Ruby/blog/script/rails console")

It returns:

apply: Spawning child process: invalid argument

My "M-x inf-ruby" work correctly. It can be launched.

The file "d:/dev/scripts/Ruby/blog/script/rails" context is following. I have the cygwin path in the exec-path.

#!/usr/bin/env ruby.exe
# This command will automatically be run when you run "rails" with Rails 3 gems installed from the root of your application.

APP_PATH = File.expand_path('../../config/application',  __FILE__)
require File.expand_path('../../config/boot',  __FILE__)
require 'rails/commands'

Thanks for taking the time to file an issue here.

Please try M-x toggle-debug-on-error. Then try rinari-console again, and you should get a stacktrace detailing what went wrong -- please paste the stacktrace into a comment here, or into a gist. Hopefully that will provide a clue! :-)

Same results without the stacktrace after 'toggle-debug-on-error'.

I think, in Windows (7), the command should be "ruby.exe d:/dev/scripts/Ruby/blog/script/rails console". But now it run the command "d:/dev/scripts/Ruby/blog/script/rails console" directly.

PS: "d:/dev/scripts/Ruby/blog/script/rails" is not a executable script.

Add the nil parameter while 'run-ruby', it sees works.

Is this as a workaround??

(defun rinari-console (&optional edit-cmd-args)
"Run a Rails console in a compilation buffer.
The buffer will support command history and links between errors
and source code. Optional prefix argument EDIT-CMD-ARGS lets the
user edit the console command arguments."
(interactive "P")
(let* ((default-directory (rinari-root))
(command (rinari--wrap-rails-command "console")))

;; Start console in correct environment.
(if rinari-rails-env
    (setq command (concat command " " rinari-rails-env)))

;; For customization of the console command with prefix arg.
(setq command (if edit-cmd-args
                  (read-string "Run Ruby: " (concat command " "))
                command))
(with-current-buffer (run-ruby nil command)
  (dolist (var '(inf-ruby-prompt-pattern inf-ruby-first-prompt-pattern))
    (set (make-local-variable var) rinari-inf-ruby-prompt-pattern))
  (rinari-launch))))

Thanks for the follow-up info.

I'll try to figure out the best general solution for this.

Please can you tell me what you see is you evaluate the following expression, e.g. with M-: --

(file-executable-p "d:/dev/scripts/Ruby/blog/script/rails")

Does it echo "t" in the minibuffer area at the bottom of the window?

"nil" for me.

Thanks, that's very helpful info. I'll see what I can do about this. :-)

I've committed a workaround, in 283180d. Perhaps you could try it and see if that helps? (You'll need to make sure that the value of ruby-compilation-executable is correct.)

Hi Purcell,
thank you for your helping.

1). My 'ruby-compilation-executable' is 'ruby'. After C-h v it,

ruby-compilation-executable is a variable defined in `ruby-compilation.el'.
Its value is "ruby"

Documentation:
What bin to use to launch the tests. Override if you use JRuby etc.

2). The rinari-console could be launched, but it misses the 'prompt'. After run it, only these are in the ruby buffer. No ">>" or "irb(main):001:0>" in there.

Loading development environment (Rails 3.2.1)
Switch to inspect mode.

3). This is what I do in the Windows CMD.

c:\dev\scripts\Ruby\blog>C:\RailsInstaller\Ruby1.9.3\bin\ruby.EXE c:\dev\scripts\Ruby\blog\script\rails console
Loading development environment (Rails 3.2.1)
irb(main):001:0>

4). In the inf-ruby.el, the 'ruby' is the "irb --inf-ruby-mode -r irb/completion" one. So for (run-ruby command), the `command is not the 'ruby' but the whole one 'ruby d:/dev/scripts/Ruby/blog/script/rails console'. It doesn't pick up any implements actually.

(defvar inf-ruby-implementations
'(("ruby" . "irb --inf-ruby-mode -r irb/completion")
("jruby" . "jruby -S irb -r irb/completion")
("rubinius" . "rbx -r irb/completion")
("yarv" . "irb1.9 --inf-ruby-mode -r irb/completion")) ;; TODO: ironruby?
"An alist of ruby implementations to irb executable names.")

You shouldn't need to change any of the inf-ruby settings. It sounds like we're making progress now, at least.

In commit 16119b6 I've made sure that the rails console buffer will be called "rails console" rather than "ruby".

Is it possible the prompt is just very slow to appear? I've seen that behaviour described elsewhere: http://stackoverflow.com/questions/10659076/unable-to-load-rails-c-error-switch-to-inspect-mode-from-within-the-other

I leave it the whole night, no prompts are shown. But I can do some commands in it, although no ">>" display.

Very strange! I'm not sure what more to suggest. I don't have a Windows machine available to test this on. :-/

Add this line to ~/.irbrc, resolve this issue, :)

IRB.conf[:PROMPT_MODE] = :SIMPLE

http://stackoverflow.com/questions/11221345/rails-console-runs-without-prompt

or
IRB.conf[:PROMPT_MODE] = :DEFAULT

Great! I'm very happy you figured it out. :-)

Hi purcell,

Thanks for you help. Although we resolve this issue, one question from me:

For function rinari--rails-path, why not check the (executable-find "rails") firstly?
Because in the any rails project, and in any shell/CMD, we run the command 'rails console' which actually run the 'rails' in the $PATH (or %PATH% in Windows), not the script/rails file. (Of course the executable rails will invoke the script/rails file, I think). For Windows, it should be like 'C:/RailsInstaller/Ruby1.9.3/bin/rails.bat console'.

Is it same in Linux? Is it need change this function?

(defun rinari--rails-path ()
"Return the path of the 'rails' command, or nil if not found."
(let* ((script (rinari-script-path))
(rails-script (expand-file-name "rails" script)))
(if (file-exists-p rails-script)
rails-script
(executable-find "rails"))))

This would cause problems with Rails 2 projects, where there might be a "rails" command in $PATH, but that command should not be used to run "script/console" etc.