Why can't we just change the signal disposition on system()?

[grocery_stocker]

This is taken from documentation:

Since "SIGINT" and "SIGQUIT" are ignored during the execution of
"system", if you expect your program to
terminate on receipt of these signals you will need to
arrange to do so yourself based on the return
value.

@args = ("command", "arg1", "arg2");
system(@args) == 0
or die "system @args failed: $?"

You can check all the failure possibilities by
inspecting $? like this:

if ($? == -1) {
print "failed to execute: $!\n";
}
elsif ($? & 127) {
printf "child died with signal %d, %s coredump
\n",
($? & 127), ($? & 128) ? 'with' :
'without';
}
else {
printf "child exited with value %d\n", $? >> 8;
}

Why can't we just trap the signal and have it exit? Ie like
sub sig {
exit;
}

$SIG{INT} = \&sig;


Chad

 

[grocery_stocker]

This is taken from documentation:

Since "SIGINT" and "SIGQUIT" are ignored during the execution of
"system", if you expect your program to
terminate on receipt of these signals you will need to
arrange to do so yourself based on the return
value.

@args = ("command", "arg1", "arg2");
system(@args) == 0
or die "system @args failed: $?"

You can check all the failure possibilities by
inspecting $? like this:

if ($? == -1) {
print "failed to execute: $!\n";
}
elsif ($? & 127) {
printf "child died with signal %d, %s coredump
\n",
($? & 127), ($? & 128) ? 'with' :
'without';
}
else {
printf "child exited with value %d\n", $? >> 8;
}

Why can't we just trap the signal and have it exit? Ie like
sub sig {
exit;
}

$SIG{INT} = \&sig;

Chad

Wait, I sat down and thought about this. system() has it's own set of
signal handlers. Since each function can like only have one signal
handler, the ones used by system() was supercede the ones I would
write.

 

[grocery_stocker]

This is taken from documentation:

Since "SIGINT" and "SIGQUIT" are ignored during the execution of
"system", if you expect your program to
terminate on receipt of these signals you will need to
arrange to do so yourself based on the return
value.

@args = ("command", "arg1", "arg2");
system(@args) == 0
or die "system @args failed: $?"

You can check all the failure possibilities by
inspecting $? like this:

if ($? == -1) {
print "failed to execute: $!\n";
}
elsif ($? & 127) {
printf "child died with signal %d, %s coredump
\n",
($? & 127), ($? & 128) ? 'with' :
'without';
}
else {
printf "child exited with value %d\n", $? >> 8;
}

Why can't we just trap the signal and have it exit? Ie like
sub sig {
exit;
}

$SIG{INT} = \&sig;

Chad

Wait, I sat down and thought about this. system() has it's own set of
signal handlers. Since each function can like only have one signal
handler per signal, the ones used by system() was supercede the ones I
would
write.

 

[Randal L. Schwartz]

grocery> Why can't we just trap the signal and have it exit? Ie like
grocery> sub sig {
grocery> exit;
grocery> }

grocery> $SIG{INT} = \&sig;

system is really just a convenience method for the following steps:

sub my_system {
my @args = @_;
defined (my $kidpid = fork) or die "Cannot fork: $!";
unless ($kidpid) { # kid does:
exec @args;
die "Cannot find $args[0]: $!";
}
# parent does:
{
local $SIG{INT} = $SIG{QUIT} = 'IGNORE';
waitpid($kidpid);
}
return $?;
}

If you want slightly different behavior, just copy this, and amend as
necessary. For example, just before the exec, you can do things like change
directory, close or open filehandles, set the process priority, and so on. In
your case, you can set up different signal handlers around the waitpid.

print "Just another Perl hacker,";