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.  <div><br></div><div>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.  </div><div><br></div><div>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"</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Similar logic applies for other tests that use pexpect.</div><div><br></div><div>Is anyone opposed to an effort to remove pexpect in this fashion?</div>