But then when it segfaults I wont be able to manage the crash,
It would be no different if you used open3(). That also starts a separate process over which you would have no control.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
| [reply] [Watch: Dir/Any] |
Well, with open3(), I can use waitpid and then read (error); which allows me some control over what happens next, if I just did
system ("perl -d:CallTrace Foo.pl");
Wouldn't it just crash? Maybe not, I should probably try it.
Regards
Steve. | [reply] [Watch: Dir/Any] [d/l] |
Well, with open3(), I can use waitpid and then read (error); which allows me some control over what happens next, if I just did system ("perl -d:CallTrace Foo.pl"); Wouldn't it just crash?
It will crash either way, the only differences is that with Re: Catching errors (II)., you can get the error code (and, on *nix at least, the 'signal value'); and then read the output from stderr.
If you use my suggested system q[perl -d:CallTrace Foo.pl 2>trace.txt];, then you can also read back the stderr output, by reading the file.
You're also more likely to get the last few lines, because you won't have the double-buffering effect you get when you use pipes.
Also, if the exit code is important to you, then (from perldoc perlfunc system ):
If you'd like to manually inspect system's failure, you can check all
+possible failure modes 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;
}
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
| [reply] [Watch: Dir/Any] [d/l] [select] |