backticks asynchronous?

[Giles Bowkett]

sorry, dumb question possibly, I just want to make sure. if I call
some Unix command using backticks, that invokes the command, launches
a new process, and waits until that process terminates before resuming
program execution, right? especially if I do this:

shell_output = `some process`

which should capture the output of the process. right? it isn't possible to say

shell_output = `some process`

and accidentally see execution fork, is it?

 

[Logan Capaldo]

sorry, dumb question possibly, I just want to make sure. if I call
some Unix command using backticks, that invokes the command, launches
a new process, and waits until that process terminates before resuming
program execution, right? especially if I do this:

shell_output = `some process`

which should capture the output of the process. right? it isn't possible to
say

shell_output = `some process`

and accidentally see execution fork, is it?

Right, ruby will wait for the process to complete.

 

[Joel VanderWerf]

Sorry, reading this email reminded me of my project. Say I wanted to do a
bunch of pings using backticks (you may have asked my stupid n00b questin
about ``). If I wanted to do a bunch of pings, which would take some small
amount of time, would it be better(faster) to start new threads before
doing
the `ping whatever`, or is there a better/different way?

Sure, why not use threads:

t0 = Time.now

threads = (1..10).map do |i|
Thread.new do
addr = "192.168.0.#{i}"
[addr, `ping -w3 -nq #{addr}`]
end
end

values = threads.map {|thread| thread.value}
t1 = Time.now
puts "Finished in #{t1 - t0} seconds"

require 'yaml'
y values.select {|addr, out| out !~ / 0 received/}

__END__

Output:

Finished in 3.011614 seconds
---
- - 192.168.0.1
- |
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.

--- 192.168.0.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 2.032/3.052/4.750/1.210 ms

...

 

[Giles Bowkett]

That depends on what you put between the back-ticks.

This:

`command > /dev/null &`

will almost certainly fork. There are any number of forking contingencies,
depending on what you try to run, and how.

well, that's probably it. the command I'm using is a very long,
involved command to a complex utility that handles media files, and
apparently takes an infinite number of command-line arguments, but the
final args are "2>&1". I inherited this code, as I understand it that
just pipes standard error and standard out to the same place --
however, now I think that might be what's going wrong.

 

[Giles Bowkett]

ok never mind about that last post. it does appear to be pipe commands
for standard out and standard err and that shouldn't result in
backgrounding.