From mboxrd@z Thu Jan  1 00:00:00 1970
From: Radim =?utf-8?B?S3LEjW3DocWZ?= <rkrcmar@redhat.com>
Subject: Re: [kvm-unit-tests PATCH v3 3/6] arch-run: reduce return code
 ambiguity
Date: Wed, 2 Mar 2016 16:42:38 +0100
Message-ID: <20160302154237.GA2354@potion.brq.redhat.com>
References: <1456772003-27911-1-git-send-email-drjones@redhat.com>
 <1456772003-27911-4-git-send-email-drjones@redhat.com>
 <56D609AC.80303@redhat.com>
 <20160302125659.GA2007@potion.brq.redhat.com>
 <56D6FC58.9010307@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: QUOTED-PRINTABLE
Cc: Andrew Jones <drjones@redhat.com>, kvm@vger.kernel.org
To: Paolo Bonzini <pbonzini@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:47329 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1752358AbcCBPml (ORCPT <rfc822;kvm@vger.kernel.org>);
	Wed, 2 Mar 2016 10:42:41 -0500
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26])
	by mx1.redhat.com (Postfix) with ESMTPS id 2898F46217
	for <kvm@vger.kernel.org>; Wed,  2 Mar 2016 15:42:41 +0000 (UTC)
Content-Disposition: inline
In-Reply-To: <56D6FC58.9010307@redhat.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

2016-03-02 15:44+0100, Paolo Bonzini:
> On 02/03/2016 13:57, Radim Kr=C4=8Dm=C3=A1=C5=99 wrote:
>> 2016-03-01 22:29+0100, Paolo Bonzini:
>>> On 29/02/2016 19:53, Andrew Jones wrote:
>>>> +	errors=3D$("${@}" 2>&1 1>&${stdout} | tee >(cat - 1>&2); exit ${=
PIPESTATUS[0]})
>>>
>>> Whoa! :)  So stdout goes to {stdout} and from there to the real std=
out;
>>> stderr instead is tee'd to stderr and $errors.
>>=20
>> Yeah. :)
>>=20
>>> Is the "tee" and "cat" necessary?  Can you just use printf somewhat=
 like:
>>=20
>> They are, if you want want to improve chances of getting the origina=
l
>> order of stdout and stderr.
>=20
> Getting the original order can't really work if you use separate file
> descriptions.

Yes, there is no "true" order ... my concern is about transparency:
tee delays stderr much less than if we buffered stderr until QEMU has
finished, so mixed stdout/stderr has better chance of being visible in
sans-wrapper order.

> I'm not sure how you would have something on stderr, except on the ve=
ry
> last line?  The idea being that 1) the test only writes to stdout 2)
> QEMU only writes to stderr 3) QEMU exits after writing to stderr.  If
> this is true, the proposed assignment/printf pair works just fine.

QEMU prints some warnings without immediately exiting, e.g.
  warning: host doesn't support requested feature: CPUID.01H:ECX.vmx [b=
it 5]

So it's possible that stdout is printed after stderr.  Preserving the
visible output could be less confusing in these rare cases.  I agree
with the late printf if you think that the ugly code is not worth it.