in reply to Re^5: Unexpected termination on "print" (docs)
in thread Unexpected termination on "print"

There was no other link or reference. I ended up assuming, given the message to go RTFM again, that the answer could be found in the $? documentation if you squint hard and look at it sideways. So that is what I did in the end to make the jump from talk about sub-processes, pipe-closes, backticks, system() operator, etc, return values *within perl* to guess that the value returned by the shell on non-normal program exit is similarly encoded. I had already checked to see if an END block was running and it wasn't, so it really seemed initially as if my case did not apply.

I have since then done some research, and it appears there have been some attempts at standardizing exit codes (see perhaps sysexit.h) and that the bash shell uses the same encoding. Most of my exit code experience however has typically been that 0 is fine, and greater than 0 means an error according to whatever the software author was thinking at the time.

  • Comment on Re^6: Unexpected termination on "print" (docs)

Replies are listed 'Best First'.
Re^7: Unexpected termination on "print" (standard)
by tye (Sage) on Aug 15, 2015 at 16:32 UTC
    I have since then done some research, and it appears there have been some attempts at standardizing exit codes (see perhaps sysexit.h) and that the bash shell uses the same encoding.

    No, this is not some convention that Perl uses and now bash also uses. See wait(2). It is part of the operating system that Perl just exposes rather directly.

    - tye