Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > Why can't we just change the signal disposition on system()?

Reply
Thread Tools

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

 
 
grocery_stocker
Guest
Posts: n/a
 
      03-24-2007
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), ($? & 12 ? '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

 
Reply With Quote
 
 
 
 
grocery_stocker
Guest
Posts: n/a
 
      03-24-2007
On Mar 23, 5:50 pm, "grocery_stocker" <(E-Mail Removed)> wrote:
> 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), ($? & 12 ? '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.

 
Reply With Quote
 
 
 
 
grocery_stocker
Guest
Posts: n/a
 
      03-24-2007
On Mar 23, 5:50 pm, "grocery_stocker" <(E-Mail Removed)> wrote:
> 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), ($? & 12 ? '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.

 
Reply With Quote
 
Randal L. Schwartz
Guest
Posts: n/a
 
      03-24-2007
>>>>> "grocery" == grocery stocker <(E-Mail Removed)> writes:

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,";

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<(E-Mail Removed)> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Aside from delta cycles and/or resolution functions, how can the effective value of a signal differ from a driving signal of its? Colin Paul Gloster VHDL 0 01-11-2007 01:31 PM
why why why why why Mr. SweatyFinger ASP .Net 4 12-21-2006 01:15 PM
findcontrol("PlaceHolderPrice") why why why why why why why why why why why Mr. SweatyFinger ASP .Net 2 12-02-2006 03:46 PM
threading.Thread vs. signal.signal Jack Orenstein Python 0 09-17-2005 11:24 PM
Async-signal safe functions in signal handlers (unix) Michael Pronath Python 1 01-03-2005 01:10 PM



Advertisments