On Mon, 2015-12-07 at 15:40 +0000, Ian Campbell wrote:
> On Mon, 2015-12-07 at 15:10 +0000, Ian Jackson wrote:
> > Ian Campbell writes ("Re: [OSSTEST PATCH 04/11] mg-debug-fail: New
> > utility script for debugging"):
> > > On Fri, 2015-12-04 at 19:35 +0000, Ian Jackson wrote:
> > > > diff --git a/mg-debug-fail b/mg-debug-fail
> > > > new file mode 100755
> > > > index 0000000..64fa235
> > > > --- /dev/null
> > > > +++ b/mg-debug-fail
> > > > @@ -0,0 +1,13 @@
> > > > +#!/bin/sh
> > > > +#
> > > > +# This script can be provided anywhere an executable or command
> > > > name
> > > > is
> > > > +# wanted. It prints its arguments, and its stdin, to its stderr,
> > > > and
> > > > +# then exits nonzero.
> > > > +#
> > > > +# When using this it may be useful to provide </dev/null as a
> > > > +# redirection for the whole program under test. Otherwise things
> > > > +# can mysteriously hang.
> > >
> > > "egrep . - /dev/null" is too noisy, it adds a "(standard input):"
> > > prefix
> > > which I don't think you want. But "egrep -h . - /dev/null" seems to
> > > remedy
> > > this without the possibility of these mysterious hangs.
> >
> > This is confusing to me. The problem is that mg-debug-fail does not
> > know whether to try to read and print its stdin. Sometimes its stdin
> > will be the stdin for some utility that it is standing in for, and
> > should be dumped. Whereas sometimes its stdin is the user's tty,
> > which should be left alone.
> >
> > This difficulty is fixed in the next patch. None of your suggestions
> > seem to address it. What problem do you think they are solving ?
>
> I think I got off on a bit of a tangent, and hadn't seen the next patch
> yet.
By which I mean:
Acked-by: Ian Campbell <ian.campb...@citrix.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
