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]

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". ;-)

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:  <%-{-{-{-<

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.