Are you forgetting to bitshift 8 bits to the right? This certainly works under my modperl.

$ cat exit.pl
#!/usr/bin/perl
print "Exiting with $ARGV[0]\n";
warn "Sending to STDERR\n";
exit $ARGV[0];

$ cat test.pl
#!/usr/bin/perl
my $output = qx! /home/www/modperl/exit.pl 42 2>&1 !;  # capture STDOU
+T + STDERR with 2>&1
my $exit_code = $? >> 8;
print "Content-Type: text/html\n\nExit: $exit_code ($?)\n$output\n";

# OUTPUT -> Exit: 42 (10752) Sending to STDERR Exiting with 42
[download]

Note: If you have installed a signal handler for SIGCHLD, the value of $? will usually be wrong outside that handler.

Thank you for your response.

Yes, I am doing the >> 8. And the "incorrectness" of $? only seems to happen after that Apache child has serviced quite a number of requests. If I change the module or do anything else that forces Apache to kill off the children containing this handler $? returns the correct value for a limited period of time. Note that this effect still occurs even if I set $? = 0 directly before qx()'ing

The other interesting thing you mention is the effect an installed handler for SIGCHLD has. I do happen to have a handler for SIGCHLD installed. I will try resetting SIGCHILD i.e. $SIG{CHLD} = '' next.

Cheers!
--habit

Also useful to know is that $? is reset on each wait or pipe close, overwriting the old value.