pexpect again

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?

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

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.

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

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).