Re: [PATCH 1/2] commands: send stderr to a new pipe

[Patrick Ohly <patrick.ohly@intel.com>]

On Thu, 2017-06-22 at 09:58 -0500, Leonardo Sandoval wrote:
> On Thu, 2017-06-22 at 16:17 +0200, Patrick Ohly wrote:
> > On Mon, 2017-06-19 at 07:39 -0700,
> > leonardo.sandoval.gonzalez@linux.intel.com wrote:
> > > From: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>
> > > 
> > > Do not mix the stderr into stdout, allowing test cases to query
> > > the specific output.
> > 
> > This changes the behavior of functions that are also used outside of
> > OE-core in a way that won't be easy to notice. I also don't think that
> > it is the right default. For example, for bitbake it is easier to
> > understand where an error occurred when stderr goes to the same stream
> > as stdout.
> 
> how would that make it easier?

Because then output will be properly interleaved, as it would be on a
console.

Actually, the entire error reporting in runCmd() only prints
result.output, so with stderr going to result.error by default, you
won't get the actual errors reported anymore at all, will you? 

> > Can't you keep the current semantic and just override it explicitly in
> > those tests that need separate stdout/stderr?
> > 
> 
> My proposed patch was mainly based on a RP's comment [1], suggesting to
> split std[out|err].

He did not suggest to change the default behavior. I agree that using
split stdout/stderr in those specific tests which specifically want to
check for error messages makes sense, but only in those tests.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.