I understand that if the error_log configuration directive is not set, then errors are sent to the SAPI error logger. For example, it is an error log in Apache or stderr in CLI.
So if I run a script from the command line, errors display directly (unless redirected). If I run a script from cron, errors are emailed to the cron job owner. So what happens if I pipe email to a script?
I'm just starting out writing a script to handle bounce messages. I've read that if the script outputs anything, it will bounce back to the sender. I wasn't sure if this applied to all output or just STDOUT. Or does STDERR equal STDOUT in CLI?
If I set error_log configuration directive to a file, can I then use trigger_error and error_log functions to safely output error messages without sending a bounce to the sender?
Since the script is processing bounces, I really want to avoid bouncing back to sender. I imagine that could cause an infinite loop. And since the error log is in another directory and the path is set in an include file, there's a remote chance something could go wrong before I can set the configuration directive. Would it be a good idea to use ini_set('error_log', 'syslog') at the very top of the script and then change it to my file as soon as I can?
When using CLI, both stdout and stderr go to the same place. For cron, output is emailed to the cron job owner. For command line, output is sent to the terminal. When passing the output of one program to another (via pipes), output is returned to the first program. What it does with it will depend on the program.
The simplest way to specify where errors go when using CLI is to specify it on the command line. So if piping email to a script, you could use the following:
| /usr/bin/php /path/to/script/script.php 2> /path/to/log/error.log
The number 2 is the file handle for stderr and the > redirects it to the specified file.
As for the different PHP configuration directives, they do behave differently for CLI. Apparently, there is a bug on some versions/systems where the error is not written to the log regardless of config settings.
Here are the results of testing with CLI on my system (PHP 5.3 on Centos 6):
log_errors is on, setting display_errors to 0 will not stop errors from displaying. Errors go to same place as stdout, unless redirected on the command line.log_errors is off and display_errors is off, no errors are reported at all.log_errors is on and error_log is set to a file (with proper permissions), then errors go to that file.log_errors is on and error_log is set to 'syslog', then errors go to /var/log/messages.log_errors is on and display_errors is on, two error messages are outputted: one with 'PHP' prefix and one without.display_errors to 1 and setting it to 'stderr' is that the former printed an extra line break.Note that I only tested the different configuration directives at the command line, not cron or piped to another program. I imagine that the results would be the same since they are all CLI. The only difference is where stdout goes.
Rather than worrying about what output might get returned to sender, you could allow the messages to go to a mailbox. Then use the PHP imap functions to read the mail. The PHP script could be run as a cron job and then any error messages would go to the cron job owner.