Re: delayed die and open3

Replies are listed 'Best First'.
Re^2: delayed die and open3 by Random_Walk (Prior) on Mar 31, 2005 at 16:43 UTC
An excellent example that makes it pretty clear what is going on, thanks. I am still puzzled though, the die runs in the child but how did the die get in there ? Is open3 forking and if so how does it decide to run the die but not the following print which comes only from the parent. Is there any way in the parent to trap failure of the child ? # here the die runs in the child: nph>perl -MIPC::Open3 -le'print "dad: $$";eval {$pid = open3(IN, OUT +, ERR, @ARGV);}; die "$$ ACK $@\n" if ($@);print <ERR>' nosuch dad: 62718 55596 ACK open3: exec of nosuch failed at -e line 1 # yet here in the same code it runs in the parent !!! nph>perl -MIPC::Open3 -le'print "dad: $$";eval {$pid = open3(IN, OUT +, ERR, @ARGV);}; die "$$ ACK $@\n" if ($@);print <ERR>' dad: 25600 25600 ACK open3(main::IN, main::OUT, main::ERR): not enough argumen +ts at -e line 1 # and if I remove the print <ERR> I alter the behaviour again nph>perl -MIPC::Open3 -le'print "dad: $$";eval {$pid = open3(IN, OUT +, ERR, @ARGV);}; die "$$ ACK $@\n" if ($@);print "moo" ' nosuch dad: 55592 moo nph> [download] Thanks, R. Pereant, qui ante nos nostra dixerunt!	[reply] [d/l]
Re^3: delayed die and open3 by tlm (Prior) on Mar 31, 2005 at 17:22 UTC
OK, try this: `use strict; use warnings; use IPC::Open3; $\|=1; print "parent pid: $$\n"; my($in, $out, $err, $pid); # duplicate stderr and stdout open( $out, ">&STDOUT" ) or die "Can't dup STDOUT to OUTPUT: $!\n"; open( $err, ">&STDERR" ) or die "Can't dup STDERR to OUTERR: $!\n"; eval { $pid = open3($in, $out, $err, @ARGV) }; die "$$ open3 gave trouble: $@\n" if $@; print "$$ It is running\n"; close $in; print "$$ stderr:\n"; print "[ $$ $_ ]" while <$err>; close $err; __END__` [download] You'll see that the child's error message is being printed by the parent. Now replace the `die` with `warn`. You'll see that if the `open3` call fails, the child goes on and tries to execute the parent's code. In other words, if the open3 call succeeds, you have a successful `fork+exec`: the child is off on its merry way executing your pipe. When you give the program a bogus argument like 'nosuch', the `fork` succeeds (hence no `$@`), but the `exec` fails. The `IPC::Open3` docs talk about `exec` failures; to trap them you need to handle the SIGPIPE yourself. the lowliest monk	[reply] [d/l] [select]
Re^3: delayed die and open3 by RazorbladeBidet (Friar) on Mar 31, 2005 at 16:46 UTC
I was asking this same question myself. Take out your "die" and it becomes evident what happens The fork inside open3 (and yes, it does fork) forks the PROCESS. The whole thing. So your parent continues to run as normal, and, as the docs for IPC::open3 say, it does NOT wait for the child to run. Therefore, the child keeps running after the parent is finished, dies and hits the die in your main program (because it forks the entire process). -------------- "But what of all those sweet words you spoke in private?" "Oh that's just what we call pillow talk, baby, that's all."	[reply]
Re^4: delayed die and open3 by Random_Walk (Prior) on Mar 31, 2005 at 17:10 UTC
Close I think but there must be more to it. If that is the case why does the child not run on through the rest of the code when the die is not in effect like fork would. `# if forked why did the child not print done too ? nph>perl -MIPC::Open3 -le'print "dad: $$";eval{$pid=open3(IN,OUT,*ER +R,@ARGV)};print "kid: $pid";print "$$ $@" if($@);print <OUT>;print "d +one $$"' ec> dad: 42996 kid: 22394 Hi done 42996 # fork does ... nph>perl -MIPC::Open3 -le'print "dad: $$";eval{$pid=fork};print "kid: +$pid";print "$$ $@" if($@);print <OUT>;print "done $$"' echo Hi dad: 33442 kid: 27366 done 33442 nph>kid: 0 done 27366 nph>` [download] Cheers, R. Pereant, qui ante nos nostra dixerunt!	[reply] [d/l]
Re^5: delayed die and open3 by RazorbladeBidet (Friar) on Mar 31, 2005 at 17:24 UTC