The IPC::Run docs say this:
run() and finish() return TRUE when all subcommands exit with a 0 result code. ... All routines raise exceptions (via die()) when error conditions are recognized. A non-zero command result is not treated as an error condition, since some commands are tests whose results are reported in their exit codes.
Which tells me that the only thing you need to check is $?, and maybe ${^CHILD_ERROR_NATIVE} if you need to, or use the IPC::Run methods ->result or ->full_result. Since none of harness(), start(), run(), or finish() are documented to set any of $!, $^E, or $@ then checking them is likely to give you false positives - as other monks have said, a successful function call does not clear any of these variables, so the content of those variables may refer to some other operation preformed previously in the script (the exception being $? <update> by which I mean it gets set to zero after a successful system or equivalent, where the external command also returns an exit code of zero to indicate success. </update>). As a general rule, the Error Variables should only be considered to be valid immediately after the failed function call that is documented to set them - note how one writes open(...) or die "Error: $!", i.e. $! is only valid when open returns false. Note how the value of $! is useless after the second (successful) open:
use warnings; use strict; open my $fh1, '<', '/thisfiledoesntexist'; warn $!; open my $fh2, '<', '/etc/passwd'; warn $!; my @lines = <$fh2>; print "Read ",0+@lines," lines\n"; __END__ No such file or directory at - line 3. Inappropriate ioctl for device at - line 4. Read 45 lines
In reply to Re: error variables after IPC::Run
by haukex
in thread error variables after IPC::Run
by CarolinaPerler
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |