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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.