Re^4: Unexpected termination on "print" (docs)

Hmm... perhaps you think I didn't read the documentation you linked to? I did, twice, but that didn't get me very far. Which either says something about my comprehension, or the quality of the documentation.

$? is a perl variable. Presumably, in the case we are discussing, print/write to a closed pipe results in $? being set, and presumably that is also what perl ends up passing back to the shell, which shifts it by 8 and eventually I end up seeing it as an integer.

How does the documentation for $? supposed to get me from the number 141 back to SIGPIPE?

update: So it turns out the shell exit code is $? directly, and not shifted like I thought. Hence:

141 >> 8 = 0
141 & 127 = 13
141 & 128 = 128
[download]

And now I see that I have something I can look up in signum.h.

Comment on Re^4: Unexpected termination on "print" (docs) Download Code

Replies are listed 'Best First'.
Re^5: Unexpected termination on "print" (docs) by afoken (Chancellor) on Aug 14, 2015 at 22:27 UTC
Hmm... perhaps you think I didn't read the documentation you linked to? I did, twice, but that didn't get me very far. Then you seem to have a real problem reading the documentation. Read the first paragraph below `$?`, and especially its last sentence. This is the first paragraph: The status returned by the last pipe close, backtick (``) command, successful call to `wait()` or `waitpid()`, or from the `system()` operator. This is just the 16-bit status word returned by the traditional Unix `wait()` system call (or else is made up to look like it). Thus, the exit value of the subprocess is really (`$? >> 8`), and `$? & 127` gives which signal, if any, the process died from, and `$? & 128` reports whether there was a core dump. What part of it don't you understand? Alexander -- Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)	[reply] [d/l] [select]
Re^5: Unexpected termination on "print" (docs) by AnomalousMonk (Archbishop) on Aug 14, 2015 at 22:29 UTC
How does the documentation for $? ... So it turns out ... Since you did not find this info in the linked documentation, can you please, for the benefit of future Seekers of Wisdom, publish a link or some other reference to the documentation or source of information that you ultimately used? Give a man a fish: `<%-{-{-{-<`	[reply] [d/l]
Re^6: Unexpected termination on "print" (docs) by mlawren (Sexton) on Aug 15, 2015 at 10:41 UTC
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.	[reply]
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	[reply]