From: Patrick Ohly <patrick.ohly@intel.com>
To: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 1/2] commands: send stderr to a new pipe
Date: Thu, 22 Jun 2017 19:39:14 +0200 [thread overview]
Message-ID: <1498153154.22706.38.camel@intel.com> (raw)
In-Reply-To: <1498148311.31575.56.camel@linux.intel.com>
On Thu, 2017-06-22 at 11:18 -0500, Leonardo Sandoval wrote:
> On Thu, 2017-06-22 at 17:59 +0200, Patrick Ohly wrote:
> > On Thu, 2017-06-22 at 10:37 -0500, Leonardo Sandoval wrote:
> > > On Thu, 2017-06-22 at 17:14 +0200, Patrick Ohly wrote:
> > > > 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?
> > > >
> > >
> > > process stderr will go into result.error and process stdout into
> > > result.output. So when the process is executed ignoring the return
> > > status, then test must check result.error. I find the latter cleaner
> > > that checking errors into stdout.
> >
> > It depends on how the result is used. That you prefer split output for
> > some tests does not mean that everyone wants the same in their tests. I
> > don't want it in my own usage of runCmd() or bitbake() because I don't
> > care about where a message was printed. I just want it in proper order.
> >
> > If you change the default, then you will also have to enhance runCmd()'s
> > error handling to include results.error. That's currently missing in
> > your patch.
>
> it is not missing, it is on 2/2
I'm talking about this code:
def runCmd(command, ignore_status=False, timeout=None, assert_error=True,
native_sysroot=None, limit_exc_output=0, **options):
...
if result.status and not ignore_status:
exc_output = result.output
if limit_exc_output > 0:
split = result.output.splitlines()
if len(split) > limit_exc_output:
exc_output = "\n... (last %d lines of output)\n" % limit_exc_output + \
'\n'.join(split[-limit_exc_output:])
if assert_error:
raise AssertionError("Command '%s' returned non-zero exit status %d:\n%s" % (command, result.status, exc_output))
else:
raise CommandError(result.status, command, exc_output)
You are not extending that in either 2/2, are you? At the moment, when a
command fails, one gets stdout+stderr. With your path, one only gets
stdout, which typically won't have the error message that caused the
non-zero status.
Here's my proposal:
1. drop the "commands: send stderr to a new pipe" path, because
that has much wider implications for everyone else
2. in "selftest/cases: use stderr data when querying for errors",
explicitly change the bitbake() calls so that they have
stderr=subprocess.PIPE
Example:
@OETestID(105)
def test_bitbake_invalid_recipe(self):
- result = bitbake('-b asdf', ignore_status=True)
- self.assertTrue("ERROR: Unable to find any recipe file matching 'asdf'" in result.output, msg = "Though asdf recipe doesn't exist, bitbake didn't output any err. message. bitbake output: %s" % result.output)
+ invalid = 'asdf'
+ result = bitbake('-b %s' % invalid, ignore_status=True, stderr=subprocess.PIPE)
+ self.assertTrue("ERROR: Unable to find any recipe file matching '%s'" % invalid in result.error, msg = "Though %s recipe doesn't exist, bitbake didn't output any err. message. bitbake output: %s" % (invalid, result.error))
--
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.
next prev parent reply other threads:[~2017-06-22 17:39 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-19 14:39 [PATCH 1/2] commands: send stderr to a new pipe leonardo.sandoval.gonzalez
2017-06-19 14:39 ` [PATCH 2/2] selftest/cases: use stderr data when querying for errors leonardo.sandoval.gonzalez
2017-06-21 10:56 ` [PATCH 1/2] commands: send stderr to a new pipe Jussi Kukkonen
2017-06-21 11:08 ` Burton, Ross
2017-06-21 15:01 ` Leonardo Sandoval
2017-06-22 14:17 ` Patrick Ohly
2017-06-22 14:58 ` Leonardo Sandoval
2017-06-22 15:14 ` Patrick Ohly
2017-06-22 15:37 ` Leonardo Sandoval
2017-06-22 15:59 ` Patrick Ohly
2017-06-22 16:18 ` Leonardo Sandoval
2017-06-22 17:39 ` Patrick Ohly [this message]
2017-06-22 20:47 ` Leonardo Sandoval
2017-06-22 21:07 ` Patrick Ohly
2017-06-22 21:27 ` Leonardo Sandoval
2017-06-22 16:59 ` Richard Purdie
2017-06-22 19:35 ` Patrick Ohly
2017-06-22 20:51 ` Leonardo Sandoval
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1498153154.22706.38.camel@intel.com \
--to=patrick.ohly@intel.com \
--cc=leonardo.sandoval.gonzalez@linux.intel.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox