Edit report at https://bugs.php.net/bug.php?id=60978&edit=1
ID: 60978
Updated by: the...@php.net
Reported by: the...@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] the...@php.net
...oh, and:
* Uncaught exception exit, `php -r 'throw new Exception("test");' ; echo $?` =
255
------------------------------------------------------------------------
[2012-02-05 09:59:54] the...@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
