From @nwc10

On Unix, this​:

$ perl -MPOSIX=​:sys_wait_h
`perl -e 'kill TERM, \$\$'`;
warn $?;
warn WIFEXITED($?) ? "E​: " . WEXITSTATUS($?) : WIFSIGNALED($?) ? "S​: " . WTERMSIG($?) : "!";

Gives this​:

15 at - line 2.
S​: 15 at - line 3.

This is good, and conforms with the documentation for `` and $?

dg ran it for me on Win32 (changing '' to "")

Terminating on signal SIGBREAK(21)
5376 at - line 2.
POSIX​::WIFEXITED not implemented on this architecture at - line 3.

That's buggy. $? indicates an *exit code* of 21, when it should be indicating
a fatal signal of 21.

What's wrong - the documentation or the implementation?

[He verified that ${^CHILD_ERROR_NATIVE} is identical to $? on Win32]

Nicholas Clark

From @ikegami

That's buggy. $? indicates an *exit code* of 21, when it should be
indicating a fatal signal of 21.

I don't think it's possible to determine the reason the process exited. Of
interest is

"For console processes, the default console control handler calls
ExitProcess when the console receives a CTRL+C or CTRL+BREAK signal."

I doubt that it's possible to determine that the child exited as a result of
ExitProcess being called, and I really don't see how it could be determined
that ExitProcess was called in response to the console catching a signal.

Verification would be appreciated.

What's wrong - the documentation or the implementation?

perlport could include a blurb.

- Eric

The RT System itself - Status changed from 'new' to 'open'

From @jandubois

On Thu, 10 Feb 2011, Eric Brine wrote​:

That's buggy. $? indicates an *exit code* of 21, when it should be
indicating a fatal signal of 21.

I don't think it's possible to determine the reason the process exited. Of
interest is

"For console processes, the default console control handler calls
ExitProcess when the console receives a CTRL+C or CTRL+BREAK signal."

I doubt that it's possible to determine that the child exited as a result of
ExitProcess being called, and I really don't see how it could be determined
that ExitProcess was called in response to the console catching a signal.

Verification would be appreciated.

I believe this is correct. You could probably run your child-process
under a custom debugger, which could trap the console control events and
channel this information back to you. That seems very heavy-handed
(process startup time penalty) for a really small gain. And it would
also mean that you would be creating 2 processes for every child, which
is not desirable either.

The only additional information you can get from GetExitCodeProcess() is
if the process is still alive or not by checking for exit code 259
(STILL_ACTIVE). It is not 100% reliable though, as there is nothing
preventing a program to call ExitProcess(STILL_ACTIVE), creating a dead
process that claims to be still running. :(

Cheers,
-Jan