Easy shell question: how to make a script killing all his childs when killed?

Ok. I am really bad at scripting, so perhaps my question is very silly, but...

I create and run a script with the content:

git rev-list --header --boundary --parents --topo-order 2229ff5c7c > /tmp/qgit_135902672.txt

Then I kill the script while it's running, but his child (git-rev-list) continues to run in background and I would like to stop it either.

So how can I write the script to be sure that when stopped, it will kill all his childern?

Thanks Marco

P.S: I have no way to exec the script in fancy ways, I can just start

Marco Costalba, Sat, Dec 09, 2006 16:16:32 +0100:

Strictly speaking: you can't. Anything you'd try will either be not portable or involve quiet complex dependencies (like perl). Are you sure you can't control each process independently?

Speaking not so strictly, you can use a script engine which supports either signal handling or exit notification (i.e. sh has traps and perl has %SIG and END{}). It's unsafe, ugly and not quiet portable to that other operating system, but it often works and is (ab)used.

Which is "fancy" enough. What do you mean "start"? Starting a new process usually and notably involves forking and execing (even if the first thing to exec will be your shell).

On 12/9/06, Alex Riesen <fork0@t-online.de> wrote:

By 'start' I mean it is done inside Qt QProcess class back box ;-)

Anyway I have written an homegrown 'wanna be hacker' launching script:

git rev-list --header --boundary --parents --topo-order HEAD > /tmp/qgit_136224752.txt & echo $! wait

With this I can get the pid of git-rev-list from my QProcess interface so to be able to kill it when needed with another command ('kill' BTW).

I have googled around and it seems that 'echo $!' and 'wait' _should_ be portable among many shell, please correct me if'm wrong or if the approach is failing (I already know it's ugly ;-) )

Marco Costalba, Sat, Dec 09, 2006 18:51:57 +0100:

Why do you need to save it in temporary file at all? Why don't you read the output like gitk does? You can take a look at popen(3). It's known to be portable among operating systems and libc's. Or, BTW, why don't you just read qprocess.h, use processIdentifier()/pid(), read*()-methods and the like? (though, looking at the QProcess in

On 12/9/06, Alex Riesen <fork0@t-online.de> wrote:

Well, I _used_ QProcess interface until last week. It's socket based and it's quite fast (much more then gitk BTW), but due to some internal buffering not so fast as reading from a file (in my last post regarding git-rev-list access there are some performance numbers to document this). It seems that socket/pipe based IPC is not as fast as file write/read. Of course we are talking of OS cached files, no disk access must be involved to keep the speed.

Probably someone more versed in IPC and OS internals could comment on this, I just base my arguments on experimental testing of various IPC systems without going deep in the reasons why the number are like this, also because I don't have the necessary knowledge.

But the fact is that with temporary (in memory) data exchange file the load time has been reduced by 40% against socket based QProcess interface.

Regarding gitk we are at least one order of magnitude faster both with QProcess and, more, with temporary files, so it's not a useful reference in this case.

  Marco

P.S: I didn't experiment with popen(). Thanks for the hint, I will

Marco Costalba, Sun, Dec 10, 2006 00:06:34 +0100:

Oh, I see now ("Fast access git-rev-list output...").

BTW, I just cannot reproduce that at all (on Linux):

    time { git rev-list --all > /tmp/ggg; cat /tmp/ggg >/dev/null; }

tends to be somewhat slower than

    time git rev-list --all | cat >/dev/null

QProcess must be doing something stupid.

Dunno. It's hard to assess on "small" repos, like kernel. They feel almost equally fast (maybe because qgit checks working directory too). Haven't tried QGit on Windows yet (does it work there?).

popen(3) usually uses pipe(2). It's also awkward with regard to shell metacharacters and signals (as system(3) is). You can use your' own buffers (setvbuf) so that could be a win against QProcess.