Bug #60978 [Opn]: exit code incorrect

Edit report at https://bugs.php.net/bug.php?id=60978&edit=1 ID: 60978 Updated by: thekid@php.net Reported by: thekid@php.net Summary: exit code incorrect Status: Open Type: Bug Package: Scripting Engine problem Operating System: Windows PHP Version: 5.4.0RC7 Block user comment: N Private report: N New Comment: Test suite: <?php if (!isset($argv[1])) { exit("*** Usage: php exit.php /path/to/php/binary\n"); } $php= realpath($argv[1]); if (!is_executable($php)) { exit("*** PHP Binary '$argv[1]' is not executable\n"); } $tests= array( "echo '';" => 0, "exit('test');" => 0, "exit(2);" => 2, "fatal();" => 255, "\$->" => 254, "throw new Exception('test');" => 255 ); foreach ($tests as $source => $expected) { $cmd= '"'.$php.'" -r "'.$source.'" 2>&1'; $output= array(); exec($cmd, $output, $actual); if ($actual === $expected) { printf("%-30s: [OK]\n", $source); } else { printf("%-30s: [FAIL, expect %d, have %d (%s)]\n", $source, $expected, $actual, implode(' ', $output)); } } ?> Previous Comments: ------------------------------------------------------------------------ [2012-02-05 10:01:41] thekid@php.net ...oh, and: * Uncaught exception exit, php -r 'throw new Exception("test");' ; echo $? = 255 ------------------------------------------------------------------------ [2012-02-05 09:59:54] thekid@php.net Your patch breaks the exitcode 254 for parse errors. We have the following cases and expected exit codes: * Clean exit, php -r 'echo "";' ; echo $? = 0 * Clean explicit exit with message, php -r 'exit("test");' ; echo $? = 0 * Clean explicit exit with exitcode, php -r 'exit(2);' ; echo $? = 2 * Exit after a fatal error, php -r '$fatal->error();' ; echo $? = 255 * Exit after compile error, php -r '$->' ; echo $? = 254 ------------------------------------------------------------------------ [2012-02-04 20:43:08] php-dev at zerocue dot com Alright, in 5.3.10@php_cli:1023 the call to zend_eval_string_ex() never returned after a zend_bailout(), if it had this bug would have been present there because zend_bailout always returns FAILURE even in non-failure cases. In 5.4 and trunk, the zend_eval_string_ex() does return and hits the exit_status=254 line. The proper fix would be to have zend_bailout not return FAILURE unless it did fail but this is a much larger change. In this case the patch simply ignores the return state of the zend_eval_string_ex() and always returns the EG(exit_status) value. ------------------------------------------------------------------------ [2012-02-04 20:00:43] php-dev at zerocue dot com This does not occur when executing a script file, only through -r. ------------------------------------------------------------------------ [2012-02-04 19:59:37] php-dev at zerocue dot com Actually my last post has nothing to do with it, mis-read the code. I don't see where the problem is, the executor_globals.exit_status is being set to two properly and the LONGJMP(bailout) still has the right exit_status value in the executor. I did confirm that this was fine in 5.3.10 but not in 5.4 or trunk. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=60978 -- Edit this bug report at https://bugs.php.net/bug.php?id=60978&edit=1