enkessler / childprocess Goto Github PK
View Code? Open in Web Editor NEWCross-platform Ruby library for managing child processes.
License: MIT License
Cross-platform Ruby library for managing child processes.
License: MIT License
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?
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?
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)
https://gist.github.com/668173
This can be avoided on *nix with Fcntl::FD_CLOEXEC, which isn't available on Windows.
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
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?
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
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
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?
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
see ffi/ffi#49
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)
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!
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
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?
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?
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
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
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?
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.
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
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
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.
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
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.
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!
Supporting Cygwin will need some special handling since it's not quite Windows and not quite Unix.
Hi,
Could you have a look at this failing test? It passes in Linux but not in Win32.
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
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
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.
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 :)
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
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
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
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.
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.
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?
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.
Is this expected?
process.io.stdin = IO.pipe[1]
undefined method `stdin=' for #ChildProcess::Windows::IO:0x53bbfa
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
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.
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 -9
ed. 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.
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?
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
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.
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
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!
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'
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
...
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>'
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
(I haven't tested on Windows, sorry, but I imagine it will be different)
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.
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]
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:in
start'�[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:in
start'�[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:in
load_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:in
first_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:in
the_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:in
block 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: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:20:in block in build_for'�[0m �[31m D:/RailsInstaller/Ruby1.9.3/lib/ruby/1.9.1/tmpdir.rb:83:in
mktmpdir'�[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:in
build'�[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:in
start'�[0m
�[31m D:/eBook/cucumber/cukes_and_cheese/android_puppies/features/support/env.rb:18:in `Before'�[0m
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/)
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?
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.