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.

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

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?

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*.

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.

Marking as wontfix for now - but Igor, feel free to fork to a System_Command2 if you like :)