php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #22796 -r option: no error messages unless display_startup_errors = On
Submitted: 2003-03-19 18:42 UTC Modified: 2003-03-31 01:56 UTC
Votes:2
Avg. Score:3.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: gk at proliberty dot com Assigned:
Status: No Feedback Package: CGI/CLI related
PHP Version: 4CVS-2003-03-19 (stable) OS: linux RH 7.2
Private report: No CVE-ID:
Have you experienced this issue?
Rate the importance of this bug to you:

 [2003-03-19 18:42 UTC] gk at proliberty dot com
I'm using php4-STABLE-200303191630
Problem is with sapi/cli/php

The problem has TWO, possibly related parts:
1. when cli/php is invoked with script argument, FATAL error messages go to /dev/stdout instead of /dev/stderr, making it difficult to handle errors properly
2. when cli/php is invoked with -r '...' option, error messages are lost ENTIRELY, although output preceding the fatal command is not.


//test.php
<?php 
echo "begin\n";
f(); // undefined function; fatal error
echo "end\n";
?>

#OUTPUT OF SCRIPT:
[greg@p3 junk]$ php "test.php" 
begin

Fatal error: Call to undefined function:  f() in /usr/local/apache/htdocs/common/test/junk/test.php on line 3
[greg@p3 junk]$ php "test.php" 1>/dev/null
[greg@p3 junk]$ php -r 'require "test.php";'
begin
[greg@p3 junk]$ 



Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-03-20 18:33 UTC] sniper@php.net
I can not reproduce this with the latest stable
snapshot:

# php -n -r 'require("test.php");'
begin
/home/jani/test.php(3) : Fatal error - Call to undefined function:  f()

Try this. ('-n' is for not using any php.ini)

 [2003-03-21 13:42 UTC] gk at proliberty dot com
I have tried your suggestion same test file and with:
php4-STABLE-200303210630 (March 21)
I get the same results:
[greg@p3 junk]$ php -n -r 'require("junk.php");'
begin
[greg@p3 junk]$ php -r 'require("junk.php");'
begin
[greg@p3 junk]$ php junk.php                 
begin

Fatal error: Call to undefined function:  f() in /usr/local/apache/htdocs/common/test/junk/junk.php on line 3
[greg@p3 junk]$ 

Perhaps the difference is in our configure options.
Mine are:
./configure --with-dom --with-zlib-dir=/usr/include --with-mysql=/usr/local/mysql --with-apxs=/usr/local/apache/bin/apxs --with-xml --enable-track-vars

Please let me know if we need to split this but into two:
have you tested the issue of error messages not going to /dev/stderr or only the -r issue?
 [2003-03-21 17:13 UTC] sniper@php.net
Try this with latest stable snapshot:

# rm config.cache 
# ./configure --disable-all --disable-cgi && make clean && make
# sapi/cli/php -n -r "require('test.php');"

I think you're just doing something wrong / have something
setup very differently in your server..

 [2003-03-21 20:09 UTC] gk at proliberty dot com
I built it again, per your instructions and get the same result:
[root@p3 php4-STABLE-200303210630]# sapi/cli/php -n -r "require('/htdocs/common/test/junk/junk.php');"
begin
[root@p3 php4-STABLE-200303210630]# 

Do I need a more recent snapshot than that?
I'm using the same test file: 
/htdocs/common/test/junk/junk.php:
<?php 
echo "begin\n";
f(); // undefined function; fatal error
echo "end\n";
?>
 [2003-03-24 17:43 UTC] iliaa@php.net
Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

I absolutely cannot replicate the problem you've described using the latest sources.
 [2003-03-31 01:56 UTC] sniper@php.net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.


..and can not reproduce..

 [2008-11-26 23:37 UTC] halmai at sol dot cc dot u-szeged dot hu
I had the same problem for a very-very long time while I managed to find out what the problem was. Maybe the reporter of this bug made the same mistake what I did. 

Shortly: the error_reporting configuration was wrong in my php.ini. 

this was bad:
error_reporting  =  E_ALL ^ E_NOTICE

this became good:
error_reporting  =  E_ALL & ~E_NOTICE

The reason was that from the manual of the error_reporting() function I just cpoied the "E_ALL ^ E_NOTICE" expression into the php.ini thinking it will be evaluated in this form. No, it will be not! Instead of the exclusive OR operator there is only AND NOT. 

Maybe this will help someone else too. :) 

Regards,

Csongor
 
PHP Copyright © 2001-2014 The PHP Group
All rights reserved.
Last updated: Mon Apr 21 04:01:57 2014 UTC