From: Richard Kettlewell on
Tom Anderson <twic(a)urchin.earth.li> writes:
> On Mon, 1 Mar 2010, Richard Kettlewell wrote:
>> Tom Anderson <twic(a)urchin.earth.li> writes:

>>> Now i just need to figure out why the script ignores SIGINT when it's
>>> suspended then backgrounded.
>>
>> At a guess, you're comparing ^C on the foreground version to
>> 'kill -INT $pid' to the background process.
>>
>> If so then the answer is probably: ^C sends a SIGINT to the entire
>> process group (and the shell runs the command in a group unique to
>> that command). So try 'kill -INT -$pid' instead.
>
> Okay, that does the job, and you have transformed my problem from "how
> do i kill the script properly?" to "what the hell is this process
> group stuff about?". Thanks!

The Glibc manual has more information:
http://www.gnu.org/s/libc/manual/html_node/Job-Control.html

When you use fg, bg, ^Z, %, etc, you're manipulating process groups.

--
http://www.greenend.org.uk/rjk/
From: Tom Anderson on
On Tue, 2 Mar 2010, Nix wrote:

> On 28 Feb 2010, Tom Anderson told this:
>
>> Firstly, i hear (from [1]) about a syntax that looks like $VARIABLE:t.
>> I've never come across that. Is this a csh thing, does bash have an
>> equivalent, and what does it do?
>>
>> Secondly, i have a script which looks like:
>>
>> someprog &
>> someotherprog &
>> quit() {
>> shutdown-someprog
>> shutdown-someotherprog
>> }
>> trap quit 0
>> while read line; do echo -n ""; done
>
> OK...
>
>> The idea is that the script starts some other programs (actually ssh
>> tunnels), then sits there doing nothing until someone sends it SIGINT
>> or SIGQUIT (or sends EOF to its stdin) something, at which point it
>> shuts then down cleanly.
>>
>> What's the best way to do the 'sit there doing nothing' part? I'm
>> using a do-nothing read loop, but that's actually not much good,
>
> Agreed.
>
> You want the underappreciated command 'wait'. Something like
>
> someprog &
> someotherprog &
>
> quit() {
> shutdown-someprog
> shutdown-someotherprog
> }
>
> trap quit SIGINT EXIT
> wait &
>
> 'wait' will exit when all the children die, and otherwise just call
> signal handlers. You can do really nifty things here, since the signal
> handlers can do pretty much anything, including redefining themselves or
> starting new processes. I've seen whole job schedulers written using
> nothing more.

Aha. I knew about wait (an earlier version of this script used it to wait
for the background processes to die before doing cleanup, instead of
having the trap thing i have now - can't remember how i arranged to have
the background processes killed, though), but it didn't occur to me to use
it here. Yes, it should do the job - the only thing it does differently to
a pure sleep is that the script will exit if all the children die, but to
be honest, that's probably a sensible thing to do. The script only exists
to manage those children, so if they die, it's time to pack up. Cheers for
the suggestion.

tom

--
THE DRUMMER FROM DEF LEPPARD'S ONLY GOT ONE ARM!
From: Nix on
On 2 Mar 2010, Chris Davies uttered the following:

> Nix <nix-razor-pit(a)esperi.org.uk> wrote:
>> wait &
>
> I really don't think that & should be there.

Er um you know what I mean. :)
From: Tom Anderson on
On Tue, 2 Mar 2010, Nix wrote:

> On 2 Mar 2010, Chris Davies uttered the following:
>
>> Nix <nix-razor-pit(a)esperi.org.uk> wrote:
>>> wait &
>>
>> I really don't think that & should be there.
>
> Er um you know what I mean. :)

Oh, that reminds me of another one that came up today. I have three
scripts, stop, prepare, and start; i need to run stop and prepare before i
can run start, but i can run stop and prepare in parallel. I can write a
master script:

stop &
prepare
wait
start

But the exact set of commands is fairly ad-hoc, due to changing parameters
and whatnot, so writing a script seems like overkill. Is there a way to do
this on the command line? This:

stop &; prepare; wait; start

Fails, apparently because the & needs to be the last thing on the line,
and a ; doesn't count as end of line. This:

(stop &); prepare; wait; start

Doesn't work, because wait doesn't wait for the parenthesised command.

I can do:

stop &
prepare; wait; start

But i'd like to have it all on one line, so that i can fish it out of my
history (and then edit it) when i need to re-run it.

There must be a way to do this, and it's probably really straightforward,
but i have no idea what it is.

Maybe i just need to write a little meta-script (with apologies to Occam):

cat >~/bin/par <<EOF
#! /bin/bash
for cmd in "$@"
do
$cmd &
done
wait # should really do better exit status handling
EOF
chmod +x ~/bin/par

Then i can say:

par stop prepare; start

tom

--
China Mieville has shown us how to be a good socialist and a bad science
fiction writer. -- The Times
From: Chris Davies on
Nix <nix-razor-pit(a)esperi.org.uk> wrote:
> Er um you know what I mean. :)

:-)
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: coLinux
Next: Deleting custom file processing from Nautilus