[lldb-dev] pexpect again

[Zachary Turner]

It's a little tricky though because of how (I assume) pexpect works.  Being
a Windows person I've never really used it, but it seems to do more than
just capture all stdin and stdout.  You can do that with subprocess.Popen.
I actually locally modified some of the code in TestSingleQuoteInFilename
to use subprocess.Popen() with stdin=PIPE, stdout=PIPE, and then
result.stdin.write() and result.stdout.read().  I was getting more all the
stdout, but it was more than what the calls to pexpect were "expecting".
For example when I read stdout I was getting the commands that were
implicitly generated by LLDB but not manually typed in by the user.  Like
the "target create" command, etc.

If there's a way to make that work, and result in cleanly written tests,
that does seem to be a nice approach though, if nothing else just in the
interest of removing dependencies (could even make the repo smaller by
removing pexpect).

On Tue Jan 20 2015 at 2:53:09 PM Greg Clayton <gclayton at apple.com> wrote:

> Another options would be to make this work using LLDB itself. pexpect is
> just launching a child process and passing STDIN and getting STDOUT/STDERR.
> Right up our alley!
>
> Greg
>
> > On Jan 20, 2015, at 1:43 PM, Zachary Turner <zturner at google.com> wrote:
> >
> > Just now I googled again and found this: https://gist.github.com/
> anthonyeden/8488763
> >
> > I must have seen this before and figured out it wouldn't work, but my
> memory escapes me now.  I will look at this again and see if it can work.
> >
> > On Tue Jan 20 2015 at 1:39:16 PM <jingham at apple.com> wrote:
> > I know that over time we have broken the lldb driver argument
> processing, and not having tests we didn't find out till some time later.
> So having tests for the driver (and indeed more than we have now because I
> am pretty sure our coverage in that area is pretty light) is a good and
> necessary thing.  The test you quote is specifically testing that the
> driver parses this argument correctly.  It should definitely stay.
> >
> > I'm curious as to why is there no pexpect for Windows?  That seems
> pretty odd to me.  Expect was ported to Windows quite some time ago, so all
> the things pexpect tries to do must be possible...
> >
> > Jim
> >
> >
> > > On Jan 20, 2015, at 1:28 PM, Zachary Turner <zturner at google.com>
> wrote:
> > >
> > > A long time ago I noted that some of the tests are using pexpect.
> pexpect doesn't exist on Windows, so we basically don't have test coverage
> for any of this stuff on Windows.  At the time I just left it alone because
> there were bigger fish to fry, but now that we have the test suite running,
> these are surfacing as failing tests.
> > >
> > > I'm going to submit a patch soon to XFAIL every test that uses pexpect
> on Windows, but I would like to propose longer term eliminating pexpect
> tests entirely.  I didn't study every single test that uses pexpect
> closely, but it seems to me that generally pexpect is used to launch lldb
> as a separate process, then send text commands to it, then check that the
> prompt looks correct.
> > >
> > > In most cases, there's no reason that we specifically need to do this
> out-of-process, and the actual functionality being tested would work just
> as well through an in-process public API test.  For example, in
> TestSingleQuoteInFilename.py, we run "./lldb --lldb-noinit "path with
> '09/a.out"
> > >
> > > What I think we should really be testing here is whether the "target
> create" command works with an argument that has a single quote in it.
> Anything that's broken between typing a command on the shell and
> formulating a "target create" command is going to something with shell
> expansion.
> > >
> > > So I think this test could be re-written to simply run a target create
> in-process using the extension module, and sanity check the resulting
> debugger state.
> > >
> > > Similar logic applies for other tests that use pexpect.
> > >
> > > Is anyone opposed to an effort to remove pexpect in this fashion?
> > > _______________________________________________
> > > lldb-dev mailing list
> > > lldb-dev at cs.uiuc.edu
> > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> >
> > _______________________________________________
> > lldb-dev mailing list
> > lldb-dev at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150120/8e94829d/attachment.html>