From: Richard Kettlewell on 2 Mar 2010 05:28 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 2 Mar 2010 08:43 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 2 Mar 2010 15:00 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 2 Mar 2010 17:13 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 2 Mar 2010 17:44
Nix <nix-razor-pit(a)esperi.org.uk> wrote: > Er um you know what I mean. :) :-) |