Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much

error variables after IPC::Run

by CarolinaPerler (Acolyte)
on Jun 19, 2017 at 15:47 UTC ( #1193101=perlquestion: print w/replies, xml ) Need Help??
CarolinaPerler has asked for the wisdom of the Perl Monks concerning the following question:

Using IPC::Run.
Would like to examine all the built-in special error variables: $@, $!, $^E, and $?. After an IPC::Run 'run', when I try to check $! and $^E, I get 'Illegal seek'.

run (\@commandArray, \$in, \$error, timeout(3)); print "LIB LEVEL ERROR: $!\n"; print "OS LEVEL ERROR: $^E\n";

On some systems in some situations, $^E is not supported. But, $! should be available. IPC::Run hands back $error (given the code above). But, it does not necessarily give back all the detail that can be gleaned from cruising through the built-in error vars. I like using IPC::Run and would like to continue doing so. But, need a robust mechanism for catching error info. It appears that IPC::Run is monkeying with $! and $^E. Any ideas on how to capture the error detail after an IPC::Run run call?

Replies are listed 'Best First'.
Re: error variables after IPC::Run
by BrowserUk (Pope) on Jun 19, 2017 at 15:55 UTC
    when I try to check $! and $^E, I get 'Illegal seek'.

    The problem with checking those error variables is that they are set by low-level operations, not the high level ones you are using.

    For example: The "Illegal Seek" message can mean that a repetitive Next File or similar operation has nothing more to return. The error makes sense in the context of the low-level seek operation, but not in the higher level Find All, where it simply means: You've got them all.

    Context is everything, and unless the module author has done a very thorough job, they will often make no sense in terms of the higher level code you are using.

    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.
    "Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity.
    In the absence of evidence, opinion is indistinguishable from prejudice. Suck that fhit
Re: error variables after IPC::Run
by haukex (Abbot) on Jun 19, 2017 at 19:02 UTC

    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
Re: error variables after IPC::Run
by choroba (Bishop) on Jun 19, 2017 at 15:59 UTC
    It usually makes no sense to examine the error variables if there was no error. Only inspect them if you know something failed (which doesn't mean IPC::Run really uses them, I'm not able to run your example code to replicate the problem).

    ($q=q:Sq=~/;[c](.)(.)/;chr(-||-|5+lengthSq)`"S|oS2"`map{chr |+ord }map{substrSq`S_+|`|}3E|-|`7**2-3:)=~y+S|`+$1,++print+eval$q,q,a,
Re: error variables after IPC::Run
by karlgoethebier (Monsignor) on Jun 19, 2017 at 16:01 UTC
    "... like using IPC::Run...robust mechanism for catching error info..."

    Perhaps this node might be inspirating: Re: Using IPC::Open3 instead of backtick operator.

    Regards, Karl

    «The Crux of the Biscuit is the Apostrophe»

    Furthermore I consider that Donald Trump must be impeached as soon as possible

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://1193101]
Approved by marto
Front-paged by Discipulus
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (10)
As of 2018-06-20 15:31 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (116 votes). Check out past polls.