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 <gclay...@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 <ztur...@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 <jing...@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 <ztur...@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@cs.uiuc.edu > > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > > > > _______________________________________________ > > lldb-dev mailing list > > lldb-dev@cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > >
_______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
