php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Request #22839 Error messages go to STDOUT instead of STDERR
Submitted: 2003-03-24 02:14 UTC Modified: 2007-07-24 14:23 UTC
From: gk at proliberty dot com Assigned: jani (profile)
Status: Closed Package: Feature/Change Request
PHP Version: 5CVS, 4CVS (2007-07-13) OS: *
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: gk at proliberty dot com
New email:
PHP Version: OS:

 

 [2003-03-24 02:14 UTC] gk at proliberty dot com 
Error messages should go to /dev/stderr instead of /dev/stdout

Example: redirect STDOUT to /dev/null; notice error message does not appear below:
[root@p3 php4-STABLE-200303210630]# sapi/cli/php -r "f();" 1>/dev/null
[root@p3 php4-STABLE-200303210630]# 

This is what you should see on /dev/stderr:
[root@p3 php4-STABLE-200303210630]# sapi/cli/php -r "f();"

Fatal error: Call to undefined function:  f() in Command line code on line 1


The problem is due to the default error handler; if you install a custom error handler function with set_error_handler() then you can work around the problem for errors except the following which CANNOT be handled with set_error_handler() function: 
E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR and E_COMPILE_WARNING.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-03-24 06:33 UTC] sniper@php.net 
Works fine when you have set it correctly in php.ini:

# php -d log_errors=1 -d error_log=/dev/stderr -r "f();" 1>/dev/null
 [2007-06-29 20:13 UTC] gk at proliberty dot com 
This is not about where  errors be LOGGED, but about what output stream to write DISPLAY output to.
I am arguing that if display_errors is enabled, then this output should go to /dev/stderr, not to /dev/stdout. 

sniper@php.net describes a workaround that co-opts use of error_log file from its intended purpose (logging errors to a file, for archival purposes) in order to redirect display output.

Most well-behaved programs distinguish between 'normal' display output and 'errors' and use /dev/stdout and /dev/sterr appropriately, in this regard.
PHP breaks this convention by displaying errors on /dev/stdout instead of /dev/stderr UNLESS you employ the workaround of setting /dev/stderr as the logfile.

If sniper's workaround is employed, however, then this prevents logging errors to a file. 

The behavior of PHP appears confused.

PHP should offer two clearly separated output mechanisms to the programmer:
1. echo() - for sending 'normal' output to /dev/stdout
2. trigger_error() - for sending 'errors' to /dev/stderr

In my case, I am running php scripts via cron. I always want to maintain a historical record, via error_log, but I also need cron to email any true errors immediately - I don't want to set error_log = /dev/stderr and lose the historical error_log record in order to accomplish this simple task that would be a no-brainer if my script was written in bash instead of php.
 [2007-07-18 15:29 UTC] jani@php.net 
I have created a patch to improve this situation a bit:

http://pecl.php.net/~jani/patches/errors_to_stderr.patch

Might need some tuning but this should work.
I overloaded the display_errors php.ini directive,
it allows using 'stderr' as parameter which makes all error messages output in CLI/CGI to go to STDERR.

Works fine in *nix, I haven't tested in Windows..
 [2007-07-24 14:23 UTC] jani@php.net 
The patch is applied to HEAD (PHP 6) and PHP_5_2 branches. 
By setting 'display_errors = "stderr"' in php.ini the error messages are outputted to STDERR. It won't affect other SAPIs than CGI/CLI, for others it's same as "On".

Note: This feature won't be added to PHP 4.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Thu Nov 21 11:01:29 2024 UTC