On Tue, Apr 7, 2015 at 6:03 PM, Martin d'Anjou
<[email protected]> wrote:
> GNU Parallel "wraps" the execution of other programs, just like shells
> do. I'd like to understand how exactly GNU Parallel behaves itself
> when it gets SIGINT/SIGQUIT. The reason I ask is because I have a
> program that performs special actions on SIGINT (a bit like emacs does
> but not quite).
When pressing CTRL-C the shell sends SIGINT to all child processes in
the foreground. So GNU Parallel cannot intercept these, but exits
instead. You can see that with:
parallel -uq perl -e '$SIG{INT}=sub {print "Got INT\n"};sleep 1000' ::: 1
<CTRL-C>
Got INT
Things get a bit more tricky when running remotely.
parallel -S server -uq perl -e 'open(A,">","/tmp/ged");$SIG{INT}=sub
{print A "Got INT\n"};sleep 1000' ::: 1
<CTRL-C>
ssh server cat /tmp/ged
<nothing>
But:
parallel -S server -uq perl -e 'open(A,">","/tmp/ged");$SIG{HUP}=sub
{print A "Got HUP\n"};sleep 1000' ::: 1
<CTRL-C>
ssh server cat /tmp/ged
Got HUP
The reason for this weirdness is described in 'man parallel_design'
under "Remote Ctrl-C and standard error (stderr)".
Nothing has been done to deal with SIGQUIT: It is not intercepted in
any way. On my system it dumps core.
/Ole
