I have several ruby processes that are started from a shell script like
this:
a&
b&
c&
z
I would like only z to respond to SIGINT and be able to interact with
the tty. But this knowledge cannot be hardcoded into the processes
themselves.
How can z detect, at run time, that it is the session leader (is that
the right term?) for this group of processes?
···
--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
in this case wouldn't
STDIN.tty?
be enought? all the background processes will return 'false' for this test i
think.
-a
···
On Thu, 6 Oct 2005, Joel VanderWerf wrote:
I have several ruby processes that are started from a shell script like
this:
a&
b&
c&
z
I would like only z to respond to SIGINT and be able to interact with
the tty. But this knowledge cannot be hardcoded into the processes
themselves.
How can z detect, at run time, that it is the session leader (is that
the right term?) for this group of processes?
--
email :: ara [dot] t [dot] howard [at] noaa [dot] gov
phone :: 303.497.6469
Your life dwells amoung the causes of death
Like a lamp standing in a strong breeze. --Nagarjuna
===============================================================================
Ara.T.Howard wrote:
I have several ruby processes that are started from a shell script like
this:
a&
b&
c&
z
I would like only z to respond to SIGINT and be able to interact with
the tty. But this knowledge cannot be hardcoded into the processes
themselves.
How can z detect, at run time, that it is the session leader (is that
the right term?) for this group of processes?
in this case wouldn't
STDIN.tty?
be enought? all the background processes will return 'false' for this
test i
think.
-a
Hey, that's right!
If you just run 'ruby a.rb&' from a shell, stdin *is* a tty, but if you
do the same from within a shell script, it's not. That's the behavior I
wanted.
$ cat >a.rb
p STDIN.tty?
$ ruby a.rb&
[1] 17042
$ true
[1] + done ruby a.rb
$ cat >a.sh
ruby a.rb&
$ chmod +x a.sh
$ ./a.sh
$ false
···
On Thu, 6 Oct 2005, Joel VanderWerf wrote:
--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
be careful - if ALL your scripts (a, b, c, z) are started from a script that
it itself not attached to a controlling tty the test will fail. since the
script that starts a, b, and c knows to put them into the background i'd
seriously consider running them all like
a &
b &
c &
LEADER=1 z
in the shell script and, in the ruby code, check by
leader = ENV['LEADER']
or something similar.
-a
···
On Thu, 6 Oct 2005, Joel VanderWerf wrote:
I have several ruby processes that are started from a shell script like
this:
a&
b&
c&
z
I would like only z to respond to SIGINT and be able to interact with
the tty. But this knowledge cannot be hardcoded into the processes
themselves.
How can z detect, at run time, that it is the session leader (is that
the right term?) for this group of processes?
in this case wouldn't
STDIN.tty?
be enought? all the background processes will return 'false' for this
test i
think.
-a
Hey, that's right!
If you just run 'ruby a.rb&' from a shell, stdin *is* a tty, but if you
do the same from within a shell script, it's not. That's the behavior I
wanted.
$ cat >a.rb
p STDIN.tty?
$ ruby a.rb&
[1] 17042
$ true
[1] + done ruby a.rb
$ cat >a.sh
ruby a.rb&
$ chmod +x a.sh
$ ./a.sh
$ false
--
email :: ara [dot] t [dot] howard [at] noaa [dot] gov
phone :: 303.497.6469
Your life dwells amoung the causes of death
Like a lamp standing in a strong breeze. --Nagarjuna
===============================================================================