Hi,

I am not against adding a method to spawn the interpreter in platform
dependent way so that script can fork the interpreter without worrying
implementation detail.  But I object to name it 'ruby' nor adding it
to 1.8.

							matz.

In message "Re: [ruby-core:34355] [Ruby 1.9-Feature#4265][Open] Provide a core method Kernel#ruby for invoking a new Ruby instance"
    on Wed, 12 Jan 2011 00:54:53 +0900, Charles Nutter <redmine / ruby-lang.org> writes:

|Many libraries re-launch Ruby to perform additional tasks. Sometimes this is done for process isolation, sometimes it's to change startup command-line for a subset of work, and sometimes it's just the easiest way to launch a clean Ruby environment. In almost every case, the command line is built using "ruby" explicitly as the command to be executed. This only works if the Ruby version/implementation you want to run is installed as "ruby" and exists on PATH. If, for example, you are running JRuby, you most likely want the subprocess to launch a new JRuby instance. I propose that we add a standard way to launch a new Ruby instance to Kernel.
|
|Kernel#ruby would launch, in an implementation-specific way, a new instance of the *current* Ruby. On normal C Ruby, this would simply use the full path to the executing "ruby" binary (using appropriate name, like "/usr/bin/ruby1.9" if necessary) and launch it directly, given the specified parameters. On implementations like JRuby, which can launch many instances in the same JVM, the Kernel#ruby method could simple launch a new instance of JRuby. In both cases, it would avoid problems with expecting libraries to build their own command line (and usually getting it wrong).
|
|The method would take, at minimum, a set of command-line parameters to the new instance. These could be in the form of an array of strings, a set of string parameters, or a single string parameter (I don't know which is best). There may be a need for non-command-line options to the #ruby method, so the array or single string might be best (for example, an option to specify whether to attempt to keep the launch in-process, using some form of MVM)
|
|The method would launch Ruby with the given command-line parameters in some implementation-specific way.
|
|The method could either return streams and pid, like p/open/3/4, or simply return the subprocess's output. There could also be a separate #ruby_open to do popen-like stream-driving.
|
|The method should be backported to 1.8.7, ideally, so that libraries could freely start to use it as soon as possible.
|
|Example usages:
|
|ruby "-e 'puts 1'"
|in, out, err = ruby "-EUTF-8", mvm:true