FAQ
Edit report at https://pear.php.net/bugs/bug.php?id=14855&edit=1

ID: 14855
Updated by: daniel.oconnor@gmail.com
Reported By: ifeghali at php dot net
Summary: execute() doesn't respects STDERR
-Status: Verified
+Status: Wont fix
Type: Bug
Package: System_Command
Package Version: 1.0.6
PHP Version: Irrelevant
-Roadmap Versions: 1.1.0
+Roadmap Versions:
New Comment:

-Status: Verified
+Status: Wont fix
-Roadmap Versions: 1.1.0
+Roadmap Versions:
Marking as wontfix for now - but Igor, feel free to fork to a
System_Command2
if you like :)


Previous Comments:
------------------------------------------------------------------------

[2008-10-23 14:48:29] cconstantine

I'm not saying it isn't a bug. My 6268 fix was only partial.

System_Command is not in beta, so the PEAR rules say "no minor
revision may introduce a BC break." So to fix it fully would require a
major version release. System_Command is poorly designed overall --
or rather, these days there are much better ways to do what it does. Any

time spent rolling a major release of System_Command seems
unnecessary.

------------------------------------------------------------------------

[2008-10-23 14:34:23] ifeghali

Yes, it is a BC break in the sense it will change the behavior of
execute() return values.
But, I do believe its a bug instead because that behavior is wrong,
according to the comments on source code:

220 * 'STDERR' Output on stderr will raise an error, even if
221 * the command's exit value is zero. The output from
222 * stderr can be retrieved using the getDebugInfo()
223 * method of the Pear_ERROR object returned by
224 * execute().;

So, whoever relied in the current behavior was coding on top of a false
design. Anyway, in the current behavior there is *no way* to retrieve
STDERR when exit code is Zero, even when we do have something written to
STDERR (because it isnt passed to PEAR_Error). IMO that fact alone
clearly demonstrates that there is a *bug*.

------------------------------------------------------------------------

[2008-10-23 14:20:24] cconstantine

It's been a while since bug 6268 (3 years!). If I recall correctly, I
opted
for only a partial fix to avoid a BC
break with respect to execute()'s return behaviour. Thus my
commentary in 6268...

"... Add a new error code and way to get at the output from stderr --
but for
backcompat execute() should NOT raise an error if the return
value is zero (regardless of stderr output.)"

Unless I'm mistaken, your patch is a BC break. Thoughts?

------------------------------------------------------------------------

[2008-10-23 13:41:03] ifeghali

Just to be clear, the correct output table would be:

+----+-----+----+----------+
OP | STD | RT | Output |
+----+-----+----+----------+
1 | 1 | 1 | STDERR |
0 | 1 | 1 | NON ZERO |
1 | 1 | 0 | STDERR |
0 | 1 | 0 | OK |
1 | 0 | 1 | NON ZERO |
0 | 0 | 1 | NON ZERO |
1 | 0 | 0 | OK |
0 | 0 | 0 | OK |
+----+-----+----+----------+

OP: 1 means STDERR option is enabled
STD: 1 means something wrote to STDERR
RT: 1 means app exit code != 0

------------------------------------------------------------------------

[2008-10-23 13:32:35] ifeghali

Description:
------------
The current code of execute() doesn't respects STDERR in the sense it
won't output STDERR when exit code is non zero, even when we do care
about STDERR. The correct logic was rewrite to a patch file.

This bug is exactly #6268 that is marked as fixed, but isn't.

------------------------------------------------------------------------

Search Discussions

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 1 of 1 | next ›
Discussion Overview
grouppear-bugs @
categoriesphp
postedDec 9, '11 at 8:42a
activeDec 9, '11 at 8:42a
posts1
users1
websitepear.php.net

1 user in discussion

Daniel Oconnor: 1 post

People

Translate

site design / logo © 2022 Grokbase