Re: [OSSTEST PATCH 04/11] mg-debug-fail: New utility script for debugging

[Ian Campbell <ian.campbell@citrix.com>]

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.campbell@citrix.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel