enkessler/childprocess

Cross-platform Ruby library for managing child processes.

childprocess's Issues

Windows JRuby 64-bit Issues

Hello hello,

Vagrant with JRuby on Windows 64-bit specifically has been seeing this error consistently:

ChildProcess::Error: Unknown error (Windows says "Operasjonen er utf\370rt.", but it did not.)
             handle_for at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/childprocess-0.3.0/lib/childprocess/windows/lib.rb:284
     windows_handle_for at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/childprocess-0.3.0/lib/childprocess/jruby.rb:48
             handle_for at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/childprocess-0.3.0/lib/childprocess/windows/lib.rb:265
  std_stream_handle_for at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/childprocess-0.3.0/lib/childprocess/windows/process_builder.rb:135
               setup_io at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/childprocess-0.3.0/lib/childprocess/windows/process_builder.rb:105
                  start at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/childprocess-0.3.0/lib/childprocess/windows/process_builder.rb:29
         launch_process at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/childprocess-0.3.0/lib/childprocess/windows/process.rb:62
                  start at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/childprocess-0.3.0/lib/childprocess/abstract_process.rb:62
                execute at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/util/subprocess.rb:56
                  chdir at org/jruby/RubyDir.java:335
                execute at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/util/subprocess.rb:55
                execute at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/util/subprocess.rb:20
                    raw at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/driver/virtualbox_base.rb:279
                   busy at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/util/busy.rb:19
                    raw at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/driver/virtualbox_base.rb:278
                execute at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/driver/virtualbox_base.rb:254
           read_version at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/driver/virtualbox.rb:117
             initialize at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/driver/virtualbox.rb:36
                reload! at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/vm.rb:129
             initialize at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/vm.rb:35
              load_vms! at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/environment.rb:426
                   each at org/jruby/RubyArray.java:1603
              load_vms! at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/environment.rb:425
                    vms at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/environment.rb:114
               multivm? at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/environment.rb:147
            vms_ordered at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/environment.rb:122
        with_target_vms at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/command/base.rb:88
                execute at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/command/up.rb:39
                execute at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/cli.rb:38
                    cli at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/environment.rb:156
                 (root) at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/bin/vagrant:43
                   load at org/jruby/RubyKernel.java:1063
                 (root) at c:\jruby-1.6.4\bin\vagrant:19

See: hashicorp/vagrant#654

Note that the above user seems to have an international machine, but this happens on American machines as well, with the translation being "The operation completed successfully." but apparently did not?

process still alive after 90 seconds (ChildProcess::TimeoutError) when starting FF

We are using Watir/Cucumber , when starting Firefox with watir, it fails with the following error "process still alive after 90 seconds (ChildProcess::TimeoutError)"
This happens sporadically but really brings down the reliability of our CI pipeline.

could you please help fix this ?
FFv25 (we are seeing this issue only after upgrading to FFv25 / Selenium-webdriver 2.39.0)
childprocess: 0.4.0
Watir-webdriver : 0.6.4
cucumber : 1.3.4
Windows win2k3 SP2

full stack trace:

13:26:16 process still alive after 90 seconds (ChildProcess::TimeoutError)
13:26:16 e:/jenkins/workspace//gems/ruby/1.9.1/gems/childprocess-0.4.0/lib/childprocess/abstract_process.rb:142:in `poll_for_exit'
13:26:16 e:/jenkins/workspace//gems/ruby/1.9.1/gems/selenium-webdriver-2.39.0/lib/selenium/webdriver/firefox/binary.rb:47:in `wait'
13:26:16 e:/jenkins/workspace//gems/ruby/1.9.1/gems/selenium-webdriver-2.39.0/lib/selenium/webdriver/firefox/launcher.rb:71:in `start_silent_and_wait'
13:26:16 e:/jenkins/workspace//gems/ruby/1.9.1/gems/selenium-webdriver-2.39.0/lib/selenium/webdriver/firefox/launcher.rb:35:in `block in launch'
13:26:16 e:/jenkins/workspace//gems/ruby/1.9.1/gems/selenium-webdriver-2.39.0/lib/selenium/webdriver/firefox/socket_lock.rb:20:in `locked'
13:26:16 e:/jenkins/workspace//gems/ruby/1.9.1/gems/selenium-webdriver-2.39.0/lib/selenium/webdriver/firefox/launcher.rb:32:in `launch'
13:26:16 e:/jenkins/workspace//gems/ruby/1.9.1/gems/selenium-webdriver-2.39.0/lib/selenium/webdriver/firefox/bridge.rb:24:in `initialize'
13:26:16 e:/jenkins/workspace//gems/ruby/1.9.1/gems/selenium-webdriver-2.39.0/lib/selenium/webdriver/common/driver.rb:31:in `new'
13:26:16 e:/jenkins/workspace//gems/ruby/1.9.1/gems/selenium-webdriver-2.39.0/lib/selenium/webdriver/common/driver.rb:31:in `for'
13:26:16 e:/jenkins/workspace//gems/ruby/1.9.1/gems/selenium-webdriver-2.39.0/lib/selenium/webdriver.rb:67:in `for'
13:26:16 e:/jenkins/workspace//gems/ruby/1.9.1/gems/watir-webdriver-0.6.4/lib/watir-webdriver/browser.rb:46:in `initialize'
13:26:16 E:/jenkins/workspace//src/core/browser_overrides/watir_webdriver_override.rb:62:in `new'
13:26:16 E:/jenkins/workspace//src/core/browser_overrides/watir_webdriver_override.rb:62:in `__start'

version bump

I think the gem needs a version bump? We're trying to get the latest updates(the fixes for windows) but it seems the version we keep getting is 0.9, which still doesn't have that. We tried adding the git url in our Gemfile but it still keeps getting the 0.9 one, instead of the head.

Suggestions?

Detecting a failure to execute the process

ChildProcess currently doesn't provide a uniform way to detect that there was a failure to execute the given process. Java differs from Linux which differs from Windows.

It would be nice if there was a uniform error I could catch that would signal that ChildProcess wasn't able to start the childprocess... though I'm not sure how to do that easily portably.

In the mean time, I'm building it in to a helper to catch the various exit cases...

For example, executing foo bar baz...

On Linux

The following comes through via the stderr of the child process:

/Users/mitchellh/.rvm/gems/ruby-1.9.3-p0/gems/childprocess-0.2.3/lib/childprocess/unix/process.rb:94:in `exec': No such file or directory - foo (Errno::ENOENT)
    from /Users/mitchellh/.rvm/gems/ruby-1.9.3-p0/gems/childprocess-0.2.3/lib/childprocess/unix/process.rb:94:in `block in launch_process'
    from /Users/mitchellh/.rvm/gems/ruby-1.9.3-p0/gems/childprocess-0.2.3/lib/childprocess/unix/process.rb:83:in `fork'
    from /Users/mitchellh/.rvm/gems/ruby-1.9.3-p0/gems/childprocess-0.2.3/lib/childprocess/unix/process.rb:83:in `launch_process'
    from /Users/mitchellh/.rvm/gems/ruby-1.9.3-p0/gems/childprocess-0.2.3/lib/childprocess/abstract_process.rb:58:in `start'
    from /Users/mitchellh/code/personal/ruby/vagrant/lib/vagrant/util/subprocess.rb:37:in `execute'
    from /Users/mitchellh/code/personal/ruby/vagrant/lib/vagrant/util/subprocess.rb:15:in `execute'
    from test.rb:7:in `<main>'

On Java

The following exception is raised directly in the parent process:

NativeException: java.io.IOException: Cannot run program "foo" (in directory "/Users/mitchellh/code/personal/ruby/vagrant"): error=2, No such file or directory
  launch_process at /Users/mitchellh/.rvm/gems/jruby-1.6.5/gems/childprocess-0.2.3/lib/childprocess/jruby/process.rb:59
           start at /Users/mitchellh/.rvm/gems/jruby-1.6.5/gems/childprocess-0.2.3/lib/childprocess/abstract_process.rb:58
         execute at /Users/mitchellh/code/personal/ruby/vagrant/lib/vagrant/util/subprocess.rb:37
         execute at /Users/mitchellh/code/personal/ruby/vagrant/lib/vagrant/util/subprocess.rb:15
          (root) at test.rb:7

On Windows

(I haven't tested on Windows, sorry, but I imagine it will be different)

Is started? meant to be private?

The Readme for childprocess demonstrates usage of started?, but started? is private in AbstractProcess. Is this intentional?

alive? suits my needs, so I don't personally don't care about started? one way or another, but it could be nice to get the Readme and AbstractProcess in sync.

io.PIPE for stdout/stderr?

Being able to tell childprocess to use IO.pipe instead of Tempfile would be a great addition, so I can just do process.io.stdout.read() without having to output to a Tempfile or provide some kind of other IO.

Right now I do stdout_r, stdout_w = IO.pipe but that requires keeping the outside stdout_r object which kind of spoils the beauty of the self contained process object :)

Windows JRuby 64-bit Issues

Hello hello,

Vagrant with JRuby on Windows 64-bit specifically has been seeing this error consistently:

ChildProcess::Error: Unknown error (Windows says "Operasjonen er utf\370rt.", but it did not.)
             handle_for at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/childprocess-0.3.0/lib/childprocess/windows/lib.rb:284
     windows_handle_for at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/childprocess-0.3.0/lib/childprocess/jruby.rb:48
             handle_for at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/childprocess-0.3.0/lib/childprocess/windows/lib.rb:265
  std_stream_handle_for at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/childprocess-0.3.0/lib/childprocess/windows/process_builder.rb:135
               setup_io at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/childprocess-0.3.0/lib/childprocess/windows/process_builder.rb:105
                  start at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/childprocess-0.3.0/lib/childprocess/windows/process_builder.rb:29
         launch_process at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/childprocess-0.3.0/lib/childprocess/windows/process.rb:62
                  start at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/childprocess-0.3.0/lib/childprocess/abstract_process.rb:62
                execute at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/util/subprocess.rb:56
                  chdir at org/jruby/RubyDir.java:335
                execute at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/util/subprocess.rb:55
                execute at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/util/subprocess.rb:20
                    raw at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/driver/virtualbox_base.rb:279
                   busy at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/util/busy.rb:19
                    raw at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/driver/virtualbox_base.rb:278
                execute at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/driver/virtualbox_base.rb:254
           read_version at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/driver/virtualbox.rb:117
             initialize at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/driver/virtualbox.rb:36
                reload! at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/vm.rb:129
             initialize at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/vm.rb:35
              load_vms! at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/environment.rb:426
                   each at org/jruby/RubyArray.java:1603
              load_vms! at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/environment.rb:425
                    vms at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/environment.rb:114
               multivm? at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/environment.rb:147
            vms_ordered at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/environment.rb:122
        with_target_vms at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/command/base.rb:88
                execute at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/command/up.rb:39
                execute at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/cli.rb:38
                    cli at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/environment.rb:156
                 (root) at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/bin/vagrant:43
                   load at org/jruby/RubyKernel.java:1063
                 (root) at c:\jruby-1.6.4\bin\vagrant:19

See: hashicorp/vagrant#654

Note that the above user seems to have an international machine, but this happens on American machines as well, with the translation being "The operation completed successfully." but apparently did not?

Is it possible to specify a new PGID for the child process?

See http://ruby-doc.org/core-1.9.3/Process.html#method-c-spawn :pgroup option.

spawn() snippet:

process group:
    :pgroup => true or 0 : make a new process group
    :pgroup => pgid      : join to specified process group
    :pgroup => nil       : don't change the process group (default)

Use case would be to kill the child processes group without killing the script that initiated the group kill.

Code in README "Advanced Example: Output to pipe" subject to deadlock

The README suggests the following code for 'Advanced Example: Output to pipe'

r, w = IO.pipe

proc = ChildProcess.build("echo", "foo")
proc.io.stdout = proc.io.stderr = w
proc.start
proc.wait

w.close
r.read #=> "test\n"

While this example works as is, somebody who follows the example, naively replacing echo foo with a command that generates more than one IO buffer's worth of data, will find that they get deadlock: the child process can't go on until the parent reads the buffer but the parent won't read until the child process finishes. E.g. try something like this:

 proc = ChildProcess.build("ruby", "-e", 'puts "x"*256000')

(This isn't hypothetical. I'm coming here after debugging a deadlock in a third-party gem; the gem author had used the example code verbatim, and my use case had larger data than the gem author had evidently tried.)

I'm no pipe wizard, but I think a more robust solution would be to do something like:

 BUFSIZ = 8192  # or anything smaller than system IO buffer size

 r, w = IO.pipe

proc = ChildProcess.build("ruby", "-e", 'puts "x"*256000')
proc.io.stdout = proc.io.stderr = w
proc.start
w.close

s = []
begin
   s << r.readpartial(BUFSIZ) while true
rescue EOFError
   # nothing to do
end

proc.wait
s.join #=> "xxxxxx..........."

(Although for this particular example, in practice the %x[] operator does what's wanted:

%x[ruby -e #{'puts "x"*256000'.shellescape}]

which is what I used in the patch I submitted to that gem.)

Anyway, bottom line, I guess I'm suggesting either making a more robust example, or adding a comment that the sample code only works for simple cases, and directing readers elsewhere for more sophisticated uses.

Cheers

process exists on noecho stdin

I'm trying to test an interactive command line app https://github.com/shellycloud/shelly
we disable echo when providing password https://github.com/shellycloud/shelly/blob/master/lib/shelly/cli/main.rb#L436

When testing with childprocess, the process exits when providing password. Is there any potential issue with IO#noecho and childprocess?

Abend: No such file or directory - shopt

This Aruba step (childprocess 0.1.7):

When I run "shopt -s xpg_echo ; echo 'one\none\none\n'"

Gives this error:

https://gist.github.com/870430

Runs fine from the cmd line:

$ shopt -s xpg_echo ; echo 'one\none\none\n'
one
one
one

$ uname -a
Linux desktop 2.6.32-30-generic #59-Ubuntu SMP Tue Mar 1 21:30:46 UTC 2011 x86_64         GNU/Linux

$ bash --version
GNU bash, version 4.1.5(1)-release (x86_64-pc-linux-gnu)

HTH

Ruby bug #921: autoload is not thread-safe

I have a hunch I'm running into Ruby bug #921: autoload is not thread-safe.

What I'm trying to do is parallelize some test automation scripts. I'm using (the awesome) ChildProcess in these scripts any time I need to use the shell. I first started with parallel-each, and ran into an intermittent bug:

uninitialized constant ChildProcess::Unix::ForkExecProcess (NameError)

Not wanting to debug an error found nowhere in Google, I simply swapped out parallel-each library for another, similar one named parallel. To my surprise, I got the same exact error. So, I created a small script that causes the bug to occur intermittently:

require 'parallel'
require 'childprocess'

Parallel.map(0..9, :in_threads => 2) do |number|
  process = ChildProcess.build("echo Hello from iteration #{number}")
  process.io.inherit!
  process.start
  process.wait
end

Here is the console output:

Hello from iteration 0
/Users/todd/.rvm/gems/ruby-1.9.3-p0/gems/childprocess-0.3.1/lib/childprocess.rb:20:in `new': uninitialized constant ChildProcess::Unix::ForkExecProcess (NameError)
  from test.rb:5:in `block in <main>'
  from /Users/todd/.rvm/gems/ruby-1.9.3-p0/gems/parallel-0.5.16/lib/parallel.rb:275:in `call'
  from /Users/todd/.rvm/gems/ruby-1.9.3-p0/gems/parallel-0.5.16/lib/parallel.rb:275:in `call_with_index'
  from /Users/todd/.rvm/gems/ruby-1.9.3-p0/gems/parallel-0.5.16/lib/parallel.rb:130:in `block (2 levels) in work_in_threads'
  from /Users/todd/.rvm/gems/ruby-1.9.3-p0/gems/parallel-0.5.16/lib/parallel.rb:123:in `loop'
  from /Users/todd/.rvm/gems/ruby-1.9.3-p0/gems/parallel-0.5.16/lib/parallel.rb:123:in `block in work_in_threads'
  from /Users/todd/.rvm/gems/ruby-1.9.3-p0/gems/parallel-0.5.16/lib/parallel.rb:14:in `block (2 levels) in in_threads'

I started to browse through the source code, and came across a Ruby command I wasn't familiar with, autoload. When Googling it, I came across the bug report mentioned above: https://www.google.com/search?q=autoload+ruby

To confirm my theory, I forked the gem, and hard-coded the Unix require:

require 'childprocess/errors'
require 'childprocess/abstract_process'
require 'childprocess/abstract_io'
require "fcntl"
require 'childprocess/unix'

I cannot reproduce the bug using the test script now.

I'm using Ruby 1.9.3p0 on Mac OS 10.7.3.

Thanks for your help!

Test suite fails with Ruby 2.0

Running the test suite against Ruby 2.0, I observe following error:

$ rspec spec
.............*...............F..

Pending:
  ChildProcess lets a detached child live on
    # how do we spec this?
    # ./spec/childprocess_spec.rb:132

Failures:

  1) ChildProcess::Unix::Process behaves like a platform that provides the child's pid knows the child's pid
     Failure/Error: process.pid.should == file.read.chomp.to_i
       expected: 21313
            got: 21310 (using ==)
     Shared Example Group: "a platform that provides the child's pid" called from ./spec/unix_spec.rb:7
     # /usr/share/ruby/tempfile.rb:324:in `open'

Finished in 2.77 seconds
32 examples, 1 failure, 1 pending

Failed examples:

rspec ./spec/pid_behavior.rb:4 # ChildProcess::Unix::Process behaves like a platform that provides the child's pid knows the child's pid

These are gems installed on my system:

$ gem list

*** LOCAL GEMS ***

bigdecimal (1.1.0)
diff-lcs (1.1.3)
io-console (0.4.1)
json (1.7.7)
psych (2.0.0)
rake (10.0.3)
rdoc (4.0.0.rc.2.1)
rspec (2.12.0)
rspec-core (2.12.2)
rspec-expectations (2.12.1)
rspec-mocks (2.12.2)

The system cannot find the file specified. (ChildProcess::Error)

Hi, I've been trying to test my app in windows and this is the result of my test(using aruba):

@announce
Scenario: Zip a single folder # features\compress_a_directory.feature:7
When I zip the directory "../../features/support/examples/test_folder" to "test_zip" # features/step_definitions/custom_steps.rb:1
$ cd C:/myapp/minizip/tmp/aruba
$ minizip
The system cannot find the file specified. (ChildProcess::Error)
./features/step_definitions/custom_steps.rb:5:in `/^I zip the directory "([^"])" to "([^"])"$/'

I did try to check my gem manually by installing it and then cding to the said directory(tmp/aruba) and then running "minizip" and it worked. The tests run in osx btw so I am stumped as to what is happening in Windows. What is the file that it is looking for? I didn't even state anything, I just ran my command line gem, so what file is this talking about? Thanks

Windows inherit STDIN tty?

Hi @jarib! Long time no talk. ChildProcess has been working great for Vagrant for years now, and I'm thankful for it.

However, I come now with a question, perhaps a bug. I'm not sure yet. Anyways, Vagrant can do things like this:

vagrant ssh -c "bash"

Under the covers, it uses ChildProcess to execute OpenSSH to execute bash. With OS X and Linux, this works as you'd want: you get a shell and you can interact with it.

On Windows, it results in this warning and error from OpenSSH:

Pseudo-terminal will not be allocated because stdin is not a terminal.
      0 [main] ssh 3600 fhandler_base::dup: dup(some disk file) failed, handle 0, Win32 error 6
dup() in/out/err failed

Now, I can hide that error on Windows by forcing OpenSSH to not allocate a the Pseudo-TTY, but then bash doesn't work at all. You get a blank output, no shell, and no input/output can go to that shell.

I realized if I set process.duplex = true, then the subprocess will have a stdin and the error above goes away (the warning stays). However, it just hangs, as if I told OpenSSH to not open a pty.

All this is to say:

Is there a way to get the child process to inherit the original tty-enabled stdin on Windows?

Upgrade ffi to 1.0 or later for ARM support

see ffi/ffi#49

Use of ChildProcess::Error as a base class for all errors

Any reason why all the errors don't extend ChildProcess::Error? Doing so would make error handling a lot easier. Now I'm doing:

begin
  process = ChildProcess.build(path, *argv)
rescue ChildProcess::LaunchError, ChildProcess::Error, SystemCallError => e
...

But without looking at the source I can't be sure that something else won't slip through.

Improve documentation + examples

Hello,

Great work on the gem, I've found it really useful!

Can you please enhance the documentation on the wiki page? It is very light!

JRuby 1.7 / Java 7 process environment

I'm using Aruba to test a rubygem and I've hit a problem that I think I can trace back to childprocess.

Background: the gem lives at /Users/joecorcoran/Projects/pannier and there is an executable file at /Users/joecorcoran/Projects/pannier/bin/pannier, as is the convention.

When using JRuby, the executable file can't be found by childprocess, despite the bin directory being added to PATH. See below for a demo of success with MRI, followed by failure with JRuby. The issue first arose during this Travis build.

$ ruby -v
ruby 1.9.3p374 (2013-01-15 revision 38858) [x86_64-darwin12.2.0]

$ irb -r childprocess

1.9.3p374 :001 > p = ChildProcess.build('pannier')
 => #<ChildProcess::Unix::ForkExecProcess:0x007f86a4a77dd0 @args=["pannier"], @started=false, @exit_code=nil, @io=nil, @cwd=nil, @detach=false, @duplex=false, @environment={}>

1.9.3p374 :002 > p.cwd = Dir.pwd
 => "/Users/joecorcoran/Projects/pannier"

1.9.3p374 :003 > p.environment['PATH'] = File.join(Dir.pwd, 'bin')
 => "/Users/joecorcoran/Projects/pannier/bin"

1.9.3p374 :004 > p.start
 => #<ChildProcess::Unix::ForkExecProcess:0x007f86a4a77dd0 @args=["pannier"], @started=true, @exit_code=nil, @io=nil, @cwd="/Users/joecorcoran/Projects/pannier", @detach=false, @duplex=false, @environment={"PATH"=>"/Users/joecorcoran/Projects/pannier/bin"}, @pid=57272>

$ ruby -v
jruby 1.7.4 (1.9.3p392) 2013-05-16 2390d3b on Java HotSpot(TM) 64-Bit Server VM 1.7.0_40-b43 +indy [darwin-x86_64]

$ irb -r childprocess

jruby-1.7.4 :001 > p = ChildProcess.build('pannier')
 => #<ChildProcess::JRuby::Process:0x665c572 @duplex=false, @cwd=nil, @detach=false, @exit_code=nil, @io=nil, @started=false, @args=["pannier"], @environment={}, @pumps=[]>

jruby-1.7.4 :002 > p.cwd = Dir.pwd
 => "/Users/joecorcoran/Projects/pannier"

jruby-1.7.4 :003 > p.environment['PATH'] = File.join(Dir.pwd, 'bin')
 => "/Users/joecorcoran/Projects/pannier/bin"

jruby-1.7.4 :004 > p.start
ChildProcess::LaunchError: Cannot run program "pannier" (in directory "/Users/joecorcoran/Projects/pannier"): error=2, No such file or directory
    from /Users/joecorcoran/.rvm/gems/jruby-1.7.4/gems/childprocess-0.3.9/lib/childprocess/jruby/process.rb:74:in `launch_process'
    from /Users/joecorcoran/.rvm/gems/jruby-1.7.4/gems/childprocess-0.3.9/lib/childprocess/abstract_process.rb:72:in `start'
    from (irb):4:in `evaluate'
    from org/jruby/RubyKernel.java:1093:in `eval'
    from org/jruby/RubyKernel.java:1489:in `loop'
    from org/jruby/RubyKernel.java:1254:in `catch'
    from org/jruby/RubyKernel.java:1254:in `catch'
    from /Users/joecorcoran/.rvm/rubies/jruby-1.7.4/bin/irb:13:in `(root)'

The two cases should work exactly the same as far as I can tell. Have I misunderstood something? Might be a Java bug, of course. I understand ProcessBuilder is quite flaky. Any thoughts?

Process#stop does not kill process tree

require 'childprocess'

File.open("test.bat", "w") do |io|
  io << '@ruby -e sleep'
end

proc = ChildProcess.build("test.bat")
proc.io.inherit!
proc.start

sleep 3

proc.stop

puts `tasklist`.split("\n").grep(/ruby/)

Unix ForkExec doesn't work with spaces in binary

I have to use ChildProcess to execute a binary with spaces and fork-exec doesn't work, it errors that the binary doesn't exist (when I actually do a file exists check above which says it does).

I tried with PosixSpawn and it works but I'd rather use fork/exec.

Thanks!

Failure on Win32: expected #to_io to return an instance of IO

There is a failure of both the code and specs. I tested version 0.2.7 on Windows XP, SP3. Here is an example failure:

1) ChildProcess preserves Dir.pwd in the child
     Failure/Error: process.start
     TypeError:
       expected #to_io to return an instance of IO
     # ./spec/../lib/childprocess/windows/lib.rb:270:in `handle_for'
     # ./spec/../lib/childprocess/windows/process_builder.rb:135:in `std_stream_handle_for'
     # ./spec/../lib/childprocess/windows/process_builder.rb:105:in `setup_io'
     # ./spec/../lib/childprocess/windows/process_builder.rb:29:in `start'
     # ./spec/../lib/childprocess/windows/process.rb:62:in `launch_process'
     # ./spec/../lib/childprocess/abstract_process.rb:62:in `start'
     # ./spec/childprocess_spec.rb:125
     # ./spec/childprocess_spec.rb:121

I had a quick look, it seems that io is sometimes the IO class and sometimes the File class. Thanks for looking into this.

-robert wahler

IO.pipe not working with Windows API?

Hey Jarib,

Not sure if I'm just doing something wrong but the following simple case seems to not work on Windows... but it should, since it is how libraries such as mixlib-shellout which powers Chef work with Windows1

require "rubygems"
require "childprocess"

proc = ChildProcess.build("ipconfig")

# Setup the stdout/stderr pipes
stdout, stdout_w = IO.pipe
stderr, stderr_w = IO.pipe
proc.io.stdout = stdout_w
proc.io.stderr = stderr_w
proc.duplex = true

proc.start

# Close our write handles, since we don't use them
stdout_w.close
stdout_err.close

# Wait for the process to exit
proc.wait

# Output the data:
p stdout.read
p stderr.read

The above will always output "" (empty string) for stdout and stderr, but if you remove all the pipe stuff (so the process just inherits the pipes), then it will properly output all the ipconfig data.

I'm not sure if I'm doing something wrong but its such a simple case I'm not sure how I can be.

Any ideas?

Invalid gemspec

Did a bundle install of my app. It is now trying to use childprocess 0.2.1 instead of 0.1.9. Keep getting the following error:

Invalid gemspec in [/usr/lib/ruby/gems/1.8/specifications/childprocess-0.2.1.gemspec]: invalid date format in specification: "2011-08-11 00:00:00.000000000Z"

Did I do something wrong, or is that on your end?

PowerShell command does not die

NOTE: Not sure if this is a childprocess issue or Powershell.

The following Powershell command will echo and then exit if executed in a CMD shell, however if the same is invoked through childprocess this doesn't happen.

PS> echo hello; exit $LASTEXITCODE

STDIN not working properly with OS X

This is a weird one. So if I run this:

p = ChildProcess.build("ruby", "-e", "p STDIN.tty?")
p.start
p.wait

I get "true" outputted, as would be expected.

But if I do this:

p = ChildProcess.build("ruby", "-e", "p STDIN.gets")
p.start
p.wait

It hangs forever. I type and hit enter and nothing happens. It is as if my keystrokes aren't reaching the child process.

Thoughts? I'm still attempting to debug but kind of stuck here.

Support environmental variables

Hi,

I started porting over the Vagrant acceptance to childprocess and I hit a roadblock when I realized there is no easy way to set the environmental variables for the child process. Every major platform supports environmental variables on a per-process basis, and the Windows CreateProcess API supports passing a block of environmental variables as well.

Unless you can think of an easier way, it would great to be able to specify environmental variables when building a process.

Best,
Mitchell

Chromedriver crashes when launched with childprocess > 0.4.0

When we start a chrome with watir-webdriver with the command :
Watir::Browser:new :chrome
you can see results here : http://stackoverflow.com/questions/21766804/chromedriver-crashes-when-lauched-from-watir-webdriver
(It's not me, but it helps to find)

It seems that it is a bug since childprocess 0.4.1 (It works good with 0.4.0 or before)

Support ffi 1.1

The 1.1.0 ffi gem was released and I had to add a constraint to my Gemfile on ffi or bundle update would go into nonstop resolution mode.

yard spews error on LICENSE

When doing a gem install with yard installed I get this message:

Installing ri documentation for childprocess-0.3.1...
Building YARD (yri) index for childprocess-0.3.1...
[error]: ParserSyntaxError: syntax error in `LICENSE`:(1,18): syntax error, unexpected tINTEGER, expecting $end
[error]: Stack trace:
    /Users/docwhat/.rvm/gems/ruby-1.9.3-p0/gems/yard-0.7.5/lib/yard/parser/ruby/ruby_parser.rb:517:in `on_parse_error'
    /Users/docwhat/.rvm/gems/ruby-1.9.3-p0/gems/yard-0.7.5/lib/yard/parser/ruby/ruby_parser.rb:49:in `parse'
    /Users/docwhat/.rvm/gems/ruby-1.9.3-p0/gems/yard-0.7.5/lib/yard/parser/ruby/ruby_parser.rb:49:in `parse'
    /Users/docwhat/.rvm/gems/ruby-1.9.3-p0/gems/yard-0.7.5/lib/yard/parser/ruby/ruby_parser.rb:15:in `parse'
    /Users/docwhat/.rvm/gems/ruby-1.9.3-p0/gems/yard-0.7.5/lib/yard/parser/source_parser.rb:438:in `parse'
    /Users/docwhat/.rvm/gems/ruby-1.9.3-p0/gems/yard-0.7.5/lib/yard/parser/source_parser.rb:361:in `parse_in_order'

ERROR:  While generating documentation for childprocess-0.3.1
... MESSAGE:   uninitialized fiber
... YARDDOC args: -c -n --quiet lib
(continuing with the rest of the installation)

Ruby: 1.9.3-p0 and 1.9.2-p290
Yard: 0.7.5

Feature Request: Wrap Existing Process

I'd like the ability to provide ChildProcess with the PID of some process (potentially started by some external script) and have it wrap the process with that PID.

Example:

process = ChildProcess.wrap(some_pid)
process.alive? #=> true
process.stop

Inconsistent IO on JRuby

While trying to fix a JRuby specific bug in Vagrant http://vagrantup.com/, which uses ChildProcess to execute some commands, I found that output cannot always be retrieved from a subprocess.

I've been able to reproduce the bug in a single file here:
https://gist.github.com/1647275

It is creating two ChildProcesses (via the Subprocess class), and executing
them in order.

Vagrant::Util::Subprocess.new("VBoxManage", "--version").execute
Vagrant::Util::Subprocess.new("VBoxManage", "--version").execute

In the execute method, a ChildProcess is created:

process = ChildProcess.build(*@command)
stdout, stdout_writer = IO.pipe
stderr, stderr_writer = IO.pipe
process.io.stdout = stdout_writer
process.io.stderr = stderr_writer
process.duplex = true

Then it tries to read the output from the stdout pipe:

data << io.read_nonblock(READ_CHUNK_SIZE)

The first time, the ChildProcess works correctly, but the second time it
yields no output.

INFO subprocess: Starting process: ["VBoxManage", "--version"]
DEBUG subprocess: Selecting on IO
DEBUG subprocess: stdout: 4.1.8r75467
DEBUG subprocess: Waiting for process to exit. Remaining to timeout: 32000
DEBUG subprocess: Exit status: 0
INFO subprocess: Starting process: ["VBoxManage", "--version"]
DEBUG subprocess: Selecting on IO
DEBUG subprocess: Waiting for process to exit. Remaining to timeout: 31999
DEBUG subprocess: Exit status: 0

I've created a workaround in Vagrant for this issue by using IO.popen4 like this:

IO.popen4( cmd ) do |pid, stdin, stdout, stderr|
 Thread.new(stdout) {|stdout_io|
   stdout_io.each_line do |data|
     @logger.debug("stdout: #{data}")
   end
 }.join
end

hashicorp/vagrant#709

But it seems that this should be pushed down into Childprocess. I'm already looking into how this could be done, but would love some advice. Thanks.

---

Reproduce with this script:
https://gist.github.com/1647275

Background:
http://markmail.org/thread/e7rmwy4jp53e3wjj
hashicorp/vagrant#658
http://jira.codehaus.org/browse/JRUBY-6362

Allow StringIO objects to be assigned as IO

I've been looking into extending childprocess to support handling input streams so Aruba can use it as a cross-platform process control library, and the first thing I tried to do with it was use StringIO objects:

require 'stringio'
require 'childprocess'
stdout = StringIO.new
cp = ChildProcess.build("ls", "/etc")
cp.io.stdout = stdout
cp.start
puts stdout.string

This fails on MRI because of the strictness of the check_type method. (It works fine on JRuby, where StringIO is duck-typed a bit better.) Is the strict type checking necessary? Being able to use anything with an IO-like interface would make childprocess much more useful, imo.

Windows JRuby 64-bit Issues

Hello hello,

Vagrant with JRuby on Windows 64-bit specifically has been seeing this error consistently:

ChildProcess::Error: Unknown error (Windows says "Operasjonen er utf\370rt.", but it did not.)
             handle_for at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/childprocess-0.3.0/lib/childprocess/windows/lib.rb:284
     windows_handle_for at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/childprocess-0.3.0/lib/childprocess/jruby.rb:48
             handle_for at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/childprocess-0.3.0/lib/childprocess/windows/lib.rb:265
  std_stream_handle_for at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/childprocess-0.3.0/lib/childprocess/windows/process_builder.rb:135
               setup_io at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/childprocess-0.3.0/lib/childprocess/windows/process_builder.rb:105
                  start at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/childprocess-0.3.0/lib/childprocess/windows/process_builder.rb:29
         launch_process at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/childprocess-0.3.0/lib/childprocess/windows/process.rb:62
                  start at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/childprocess-0.3.0/lib/childprocess/abstract_process.rb:62
                execute at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/util/subprocess.rb:56
                  chdir at org/jruby/RubyDir.java:335
                execute at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/util/subprocess.rb:55
                execute at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/util/subprocess.rb:20
                    raw at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/driver/virtualbox_base.rb:279
                   busy at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/util/busy.rb:19
                    raw at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/driver/virtualbox_base.rb:278
                execute at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/driver/virtualbox_base.rb:254
           read_version at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/driver/virtualbox.rb:117
             initialize at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/driver/virtualbox.rb:36
                reload! at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/vm.rb:129
             initialize at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/vm.rb:35
              load_vms! at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/environment.rb:426
                   each at org/jruby/RubyArray.java:1603
              load_vms! at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/environment.rb:425
                    vms at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/environment.rb:114
               multivm? at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/environment.rb:147
            vms_ordered at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/environment.rb:122
        with_target_vms at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/command/base.rb:88
                execute at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/command/up.rb:39
                execute at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/cli.rb:38
                    cli at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/lib/vagrant/environment.rb:156
                 (root) at c:/jruby-1.6.4/lib/ruby/gems/1.8/gems/vagrant-0.9.1/bin/vagrant:43
                   load at org/jruby/RubyKernel.java:1063
                 (root) at c:\jruby-1.6.4\bin\vagrant:19

See: hashicorp/vagrant#654

Note that the above user seems to have an international machine, but this happens on American machines as well, with the translation being "The operation completed successfully." but apparently did not?

windows process.io.stdin unavailable?

Is this expected?

process.io.stdin = IO.pipe[1]

undefined method `stdin=' for #ChildProcess::Windows::IO:0x53bbfa

Windows Process#wait holds GIL

I'm sorry i don't have a minimal test case. But I used to have code that looked like this:

Thread.new do 
  # do things forever
end

p = ChildProcess.buid("some-long-running-process")
p.start
p.wait

During this process, the thread would never be yielded to. The p.wait effectively locked up the whole Ruby VM. On the other hand, when I replaced it with this:

while !p.exited?
  sleep 0.1
end

Everything worked great.

I'm not sure if there is a good solution to this or why this happens. But it'd be just great if the Lib.wait_for_single_object could release the GIL. Not sure if FFI supports that.

License missing from gemspec

Some companies will only use gems with a certain license.
The canonical and easy way to check is via the gemspec
via e.g.

spec.license = 'MIT'
# or
spec.licenses = ['MIT', 'GPL-2']

There is even a License Finder to help companies ensure all gems they use
meet their licensing needs. This tool depends on license information being available in the gemspec.
Including a license in your gemspec is a good practice, in any case.

How did I find you?

I'm using a script to collect stats on gems, originally looking for download data, but decided to collect licenses too,
and make issues for missing ones as a public service :)
https://gist.github.com/bf4/5952053#file-license_issue-rb-L13 So far it's going pretty well

Aruba 0.4.3 specs won't run on Win32 due to quoted argument handling

Hi,

Could you have a look at this failing test? It passes in Linux but not in Win32.

robertwahler@5d804d3

I think it is causing more than 1/2 of Aruba 0.4.3 specs to fail on Win32. Any Aruba test that uses quoted args like the following Aruba Cucumber feature fail on Win32.

Scenario: non-zero exit status
    When I run `ruby -e 'exit 56'`
    Then the exit status should be 56
    And the exit status should not be 0

Thanks!

-robert wahler

chdir support

Hello,

I realize this is possible to build on top of childprocess but is something so common when creating child processes that I think childprocess itself should build in support for chdir.

I haven't used childprocess very long so I'm not entirely sure what the API would look like, but this is very important for me. If I begin to use childprocess more heavily I'll investigate adding this myself, but that may not be for some time.

Thanks,
Mitchell

ChildProcess::LaunchError: No such file or directory with 0.3.7 release.

Hi,

Some user of guard-spork get this error: ChildProcess::LaunchError: No such file or directory with the last release, any ideas?

Thanks!

Issue: guard/guard-spork#107

How to pipe from one child process to another?

I can't set stdin so I can't figure out how to pipe from one child to another.

require 'childprocess'

keywords = %w(redis memcached)

# Building "ps aux | grep 'redis|memcached'"
listing = ChildProcess.build("ps", "aux")
search = ChildProcess.build("grep", '-E', keywords.join('|'))
search.io.stdin = listing.io.stdout # doesn't work!
search.io.output = STDOUT
listing.start
search.start

listing.wait
search.wait

Any advice?

cygwin support

Supporting Cygwin will need some special handling since it's not quite Windows and not quite Unix.

Feature Request: Prevent Orphaned Processes

It would be really nice is if there was a way to ensure that child processes get killed when the parent processes exits or gets kill -9ed. Obviously you don't want this to happen all the time (e.g. you might be creating a daemon), but in many cases this would be a very useful feature.

Failing duplex test under JRuby 1.6.5

When running the specs under JRuby 1.6.5 I get the following failure:

  1) ChildProcess can write to stdin if duplex = true
     Failure/Error: out.read.should == "hello world"
       expected: "hello world"
            got: "" (using ==)
     # ./spec/childprocess_spec.rb:162:in `(root)'

My environment:

$ ruby -v
jruby 1.6.5 (ruby-1.8.7-p330) (2011-10-25 9dcd388) (Java HotSpot(TM) 64-Bit Server VM 1.6.0_29) [darwin-x86_64-java]

I did some digging and found out that the STDIN.read in the test returns an empty string instead of any data that was sent to standard input.

FFI issues on 64-bit Windows

Howdy @jarib!

I've got some Vagrant users that are reporting problems with FFI on 64-bit Windows. Vagrant no longer relies on FFI directly and the only dependency that needs it is childprocess, so I delegate this issue to you :) I've done my best to see what is going on but didn't get far.

Issue: hashicorp/vagrant#648

I found some stackoverflow knowledge that notes that changing FFI versions somehow fixes things but I don't know why.

Based on my experience using FFI for 2 years with Vagrant prior to ditching it, I have to say that FFI is awesome, but the patch releases are really scary, so if you can minimize your dependence down as much as possible, I'd recommend it.

Mitchell

Cucumber (ChildProcess::LaunchError) on WIndows7 64bit

When running cucumber features against an android application running on a windows 7 64bit machine I get Unknown error (Windows says "The operation completed successfully.", but it did not.) (ChildProcess::LaunchError).

ruby 1.9.3p125 (2012-02-16) [i386-mingw32]

bundle update

Using rake (10.1.0)
Using ffi (1.9.0)
Using childprocess (0.3.9)
Using ADB (0.5.6)
Using brazenhead (0.4.7)
Using builder (3.2.2)
Using diff-lcs (1.2.4)
Using multi_json (1.7.7)
Using gherkin (2.12.0)
Using multi_test (0.0.1)
Using cucumber (1.3.3)
Using i18n (0.6.4)
Using faker (1.1.2)
Using yml_reader (0.2)
Using data_magic (0.14)
Using page_navigation (0.9)
Using gametel (0.7)
Using require_all (1.2.1)
Using rspec-core (2.14.1)
Using rspec-expectations (2.14.0)
Using rspec-mocks (2.14.1)
Using rspec (2.14.0)
Using bundler (1.0.22)

---

�[31m Unknown error (Windows says "The operation completed successfully.", but it did not.) (ChildProcess::LaunchError)�[0m
�[31m D:/RailsInstaller/Ruby1.9.3/lib/ruby/gems/1.9.1/gems/childprocess-0.3.9/lib/childprocess/windows/process_builder.rb:87:in create_process'�[0m �[31m D:/RailsInstaller/Ruby1.9.3/lib/ruby/gems/1.9.1/gems/childprocess-0.3.9/lib/childprocess/windows/process_builder.rb:34:instart'�[0m
�[31m D:/RailsInstaller/Ruby1.9.3/lib/ruby/gems/1.9.1/gems/childprocess-0.3.9/lib/childprocess/windows/process.rb:63:in launch_process'�[0m �[31m D:/RailsInstaller/Ruby1.9.3/lib/ruby/gems/1.9.1/gems/childprocess-0.3.9/lib/childprocess/abstract_process.rb:72:instart'�[0m
�[31m D:/RailsInstaller/Ruby1.9.3/lib/ruby/gems/1.9.1/gems/brazenhead-0.4.7/lib/brazenhead/process.rb:12:in run'�[0m �[31m D:/RailsInstaller/Ruby1.9.3/lib/ruby/gems/1.9.1/gems/brazenhead-0.4.7/lib/brazenhead/manifest_info.rb:32:inload_manifest'�[0m
�[31m D:/RailsInstaller/Ruby1.9.3/lib/ruby/gems/1.9.1/gems/brazenhead-0.4.7/lib/brazenhead/manifest_info.rb:28:in manifest'�[0m �[31m D:/RailsInstaller/Ruby1.9.3/lib/ruby/gems/1.9.1/gems/brazenhead-0.4.7/lib/brazenhead/manifest_info.rb:37:infirst_capture'�[0m
�[31m D:/RailsInstaller/Ruby1.9.3/lib/ruby/gems/1.9.1/gems/brazenhead-0.4.7/lib/brazenhead/manifest_info.rb:7:in package'�[0m �[31m D:/RailsInstaller/Ruby1.9.3/lib/ruby/gems/1.9.1/gems/brazenhead-0.4.7/lib/brazenhead/builder.rb:68:inthe_target'�[0m
�[31m D:/RailsInstaller/Ruby1.9.3/lib/ruby/gems/1.9.1/gems/brazenhead-0.4.7/lib/brazenhead/builder.rb:58:in update_test_manifest'�[0m �[31m D:/RailsInstaller/Ruby1.9.3/lib/ruby/gems/1.9.1/gems/brazenhead-0.4.7/lib/brazenhead/builder.rb:30:inblock in install_server'�[0m
�[31m D:/RailsInstaller/Ruby1.9.3/lib/ruby/gems/1.9.1/gems/brazenhead-0.4.7/lib/brazenhead/builder.rb:28:in chdir'�[0m �[31m D:/RailsInstaller/Ruby1.9.3/lib/ruby/gems/1.9.1/gems/brazenhead-0.4.7/lib/brazenhead/builder.rb:28:ininstall_server'�[0m
�[31m D:/RailsInstaller/Ruby1.9.3/lib/ruby/gems/1.9.1/gems/brazenhead-0.4.7/lib/brazenhead/builder.rb:20:in block in build_for'�[0m �[31m D:/RailsInstaller/Ruby1.9.3/lib/ruby/1.9.1/tmpdir.rb:83:inmktmpdir'�[0m
�[31m D:/RailsInstaller/Ruby1.9.3/lib/ruby/gems/1.9.1/gems/brazenhead-0.4.7/lib/brazenhead/builder.rb:19:in build_for'�[0m �[31m D:/RailsInstaller/Ruby1.9.3/lib/ruby/gems/1.9.1/gems/brazenhead-0.4.7/lib/brazenhead/server.rb:26:inbuild'�[0m
�[31m D:/RailsInstaller/Ruby1.9.3/lib/ruby/gems/1.9.1/gems/brazenhead-0.4.7/lib/brazenhead/server.rb:15:in start'�[0m �[31m D:/RailsInstaller/Ruby1.9.3/lib/ruby/gems/1.9.1/gems/gametel-0.7/lib/gametel.rb:41:instart'�[0m
�[31m D:/eBook/cucumber/cukes_and_cheese/android_puppies/features/support/env.rb:18:in `Before'�[0m

ChildProcess::LaunchError when running `bundle <anything>`

For some reason, I'm getting the following error whenever I try to run bundle with ChildProcess:

irb(main):001:0> require 'childprocess'
=> true
irb(main):002:0> ChildProcess.build(*%w[bundle --help]).tap{|ps| ps.io.inherit! }.start
ChildProcess::LaunchError: Unknown error (Windows says "The operation completed successfully.", but it did not.)
        from c:/RailsInstaller/Ruby1.9.3/lib/ruby/gems/1.9.1/gems/childprocess-0.3.9/lib/childprocess/windows/process_builder.rb:87:in `create_process'
        from c:/RailsInstaller/Ruby1.9.3/lib/ruby/gems/1.9.1/gems/childprocess-0.3.9/lib/childprocess/windows/process_builder.rb:34:in `start'
        from c:/RailsInstaller/Ruby1.9.3/lib/ruby/gems/1.9.1/gems/childprocess-0.3.9/lib/childprocess/windows/process.rb:63:in `launch_process'
        from c:/RailsInstaller/Ruby1.9.3/lib/ruby/gems/1.9.1/gems/childprocess-0.3.9/lib/childprocess/abstract_process.rb:72:in `start'
        from (irb):2
        from c:/RailsInstaller/Ruby1.9.3/bin/irb:12:in `<main>'

That error message isn't very helpful. So Windows is saying that everything's fine but you say Windows is lying because... why?

Open3 has no problem running the bundle command:

irb(main):001:0> require 'open3'
=> true
irb(main):002:0> sin, sout, serr, thread = Open3.popen3(*%w[bundle --help])
=> [#<IO:fd 4>, #<IO:fd 5>, #<IO:fd 7>, #<Thread:0x14bff98 run>]
irb(main):003:0> puts sout.read
<output of bundle --help is displayed here>
=> nil

doesn't work with bundler

consider following script:

require 'rubygems'
require 'childprocess'
env = {}
@process = ChildProcess.build "bundle exec spork"
@process.environment.merge!(env)
puts "works"
@process.io.inherit!
@process.start
@pid = @process.pid
sleep 2
p @pid
p @process.alive?

works ok if I run it normally:

$ ruby contrib/test_childprocess.rb 
works
22576
true

but, if I run it with bundler:

$ bundle exec ruby contrib/test_childprocess.rb 
contrib/test_childprocess.rb:5: undefined method `environment' for #<ChildProcess::Unix::Process:0x7f65379f53f0> (NoMethodError)

So, basically childprocess doesn't work if it is used in any gem which is called with bundle exec,

for example I run bundle exec guard , guard loads guard-spork, guard-spork uses ChildProces and everything is broken.

io.inherit! also inherits open sockets

https://gist.github.com/668173

This can be avoided on *nix with Fcntl::FD_CLOEXEC, which isn't available on Windows.

Windows: Calling Process#wait after Process#exited? returns true crashes (should be easy)

This should be an easy one for you, since you can just keep track of a boolean in Ruby. Easily reproducible:

p = ChildProcess.build("ruby", "--version").start
while !p.exited?
  # hot loop
end
p.wait

Crashes with "Operation completed successfully" error.