Backticks asynchronous?

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?

On Mon, Nov 20, 2006 at 08:05:45AM +0900, Giles B. wrote:

shell_output = some process

and accidentally see execution fork, is it?

Right, ruby will wait for the process to complete.

Giles B. wrote:

shell_output = some process

and accidentally see execution fork, is it?

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.

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?

Jason M. wrote:

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

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.

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.