# [PATCH] Send errors to stderr instead of stdout

- Thread: https://externals.io/message/11316
- Original archive: https://news-web.php.net/php.internals/11316
- Started by Johannes Schlueter on 2004-07-18T00:10:08+00:00
- Messages: 3
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #11316 — Johannes Schlueter — 2004-07-18T00:10:08+00:00

URL: https://externals.io/message/11316#11316

Hi,

while developping some shell scripts with PHP-cli I've got annoyed that PHP 
sends its error messages to `STDOUT` instead of `STDERR` so I've written the 
attached patch.

I see two possible problems with this patch where I'm not sure if one of the 
is really critical:
  - it uses the PHP STDERR constant defined by PHP-cli. If one doesn't use 
PHP-cli and defines a constant with this name which is not a stream-resource 
PHP segfaults. (How do I check wether a resource is a stream-resource?)
  - there are a few tests checking for error messages and at least 
ext/standard/tests/file/userstreams.phpt failed for me after applying this 
patch but other tests testing for error messages worked and I'm not sure why 
they behave different. (some I/O-Buffers?)

The patch was developped and tested on my i686-pc-linux-gnu box against HEAD.

johannes

PS: The PHP version of HEAD is still 5.0.1-dev but should be 5.1.0-dev, since 
5.0.1 is afaik developped in the PHP_5_0 branch. I also added a patch to 
update these numbers.

---

## #11317 — Wez Furlong — 2004-07-18T01:43:20+00:00

URL: https://externals.io/message/11316#11317 · In reply to: #11316

Two technical points:

1/ You *must not* use php_stream_from_zval except within a
PHP_FUNCTION unless you really know what you're doing.  Use
php_stream_from_zval_no_verify instead, and manually check to see if
you ended up with a valid stream pointer.  The segfault problem you
had was because you were misusing this macro.

2/ Why not simply fprintf(stderr, STR_PRINT(prepend_string) ........ ?

and a third SAPI compatibility point: stderr is not consistently
handled across SAPI, so stdout is the "best" place for the error
output.  If your patch were to be accepted, it would require that you
check if the active sapi is CLI before sending the output to stderr,
instead of piping it into the output buffer.

Of course, breaking the test suite for CLI isn't the best news either;
it relies on the output ending up in stdout.

--Wez.


> Hi,
> 
> while developping some shell scripts with PHP-cli I've got annoyed that PHP
> sends its error messages to `STDOUT` instead of `STDERR` so I've written the
> attached patch.
> 
> I see two possible problems with this patch where I'm not sure if one of the
> is really critical:
>   - it uses the PHP STDERR constant defined by PHP-cli. If one doesn't use
> PHP-cli and defines a constant with this name which is not a stream-resource
> PHP segfaults. (How do I check wether a resource is a stream-resource?)
>   - there are a few tests checking for error messages and at least
> ext/standard/tests/file/userstreams.phpt failed for me after applying this
> patch but other tests testing for error messages worked and I'm not sure why
> they behave different. (some I/O-Buffers?)
> 
> The patch was developped and tested on my i686-pc-linux-gnu box against HEAD.
> 
> johannes
> 
> PS: The PHP version of HEAD is still 5.0.1-dev but should be 5.1.0-dev, since
> 5.0.1 is afaik developped in the PHP_5_0 branch. I also added a patch to
> update these numbers.

---

## #11319 — Marcus Boerger — 2004-07-18T11:28:42+00:00

URL: https://externals.io/message/11316#11319 · In reply to: #11317

Hello Wez,

Sunday, July 18, 2004, 3:43:20 AM, you wrote:

> Of course, breaking the test suite for CLI isn't the best news either;
> it relies on the output ending up in stdout.

While rewriting his patch to check for CLI he could possibly either
add a switch for CLI to error to stdout or to catch stderr in the
test environment.

marcus