interact() missing coverage for (OSError, EIO), reading after child exit

[jself]

I was able to duplicate the OSError while using stdin and vim:
pexpect.spawn('vim')
pexpect.interact()

added the breaks since there shouldn't be a local data that's valid after the exception

---

jquast: this bug was for pexpect2.4 and does not occur with 3.0.
However, some related tests should be implemented (and possibly, fixes).

[jquast]

Is there something in particular I should do to cause it to reproduce while using vim ?

import pexpect
pexpect.spawn('vim').interact()

I'm in VIM as expected, but, now what? (edited for formatting)

[jself]

It may require tmux, though I'm able to duplicate it either with tmux or not. The original situation that caused this was wrapping a git merge --no-ff which opens vim as my default editor inside of tmux

[jquast]

Ahh maybe I see it now? Reproduced when using pexpect as available on pypi.org (version 2.4).

$ deactivate
$ virtualenv /tmp/ENVx
$ . /tmp/ENVx/bin/activate
$ pip install pexpect
$ python -c 'import pexpect; pexpect.spawn("vim").interact()'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/tmp/ENV/local/lib/python2.7/site-packages/pexpect.py", line 1497, in interact
    self.__interact_copy(escape_character, input_filter, output_filter)
  File "/tmp/ENV/local/lib/python2.7/site-packages/pexpect.py", line 1525, in __interact_copy
    data = self.__interact_read(self.child_fd)
  File "/tmp/ENV/local/lib/python2.7/site-packages/pexpect.py", line 1515, in __interact_read
    return os.read(fd, 1000)
OSError: [Errno 5] Input/output error

Can you also reproduce this, using pexpect, from github.com?

$ deactivate
$ virtualenv /tmp/ENV
$ . /tmp/ENV/bin/activate
$ pip install git+https://github.com/pexpect/pexpect.git
$ python -c 'import pexpect; pexpect.spawn("vim").interact()'

I can't...

[jself]

Ah, nope, it looks good, sorry. The problem was that I still had a
pexpect.pyc in my virtualenv from before I had tried the git version.

On Sat, Nov 9, 2013 at 6:50 PM, Jeff Quast notifications@github.com wrote:

Ahh maybe I see it now? Reproduced when using pexpect as available on
pypi.org (version 2.4).

$ deactivate
$ virtualenv /tmp/ENVx
$ . /tmp/ENVx/bin/activate
$ pip install pexpect
$ python -c 'import pexpect; pexpect.spawn("vim").interact()'
Traceback (most recent call last):
File "", line 1, in
File "/tmp/ENV/local/lib/python2.7/site-packages/pexpect.py", line 1497, in interact
self.__interact_copy(escape_character, input_filter, output_filter)
File "/tmp/ENV/local/lib/python2.7/site-packages/pexpect.py", line 1525, in __interact_copy
data = self.__interact_read(self.child_fd)
File "/tmp/ENV/local/lib/python2.7/site-packages/pexpect.py", line 1515, in __interact_read
return os.read(fd, 1000)
OSError: [Errno 5] Input/output error

Can you also reproduce this, using pexpect, from github.com?

$ deactivate
$ virtualenv /tmp/ENV
$ . /tmp/ENV/bin/activate
$ pip install git+https://github.com/pexpect/pexpect.git
$ python -c 'import pexpect; pexpect.spawn("vim").interact()'

I can't...

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/23#issuecomment-28140083
.

[takluyver]

So the conclusion is that the current version in git doesn't exhibit this bug, then? Do we want to close this PR, or are there still situations where the problem might come up?

[jquast]

I'm wondering if it may be related to (and hey, maybe even possibly resolve) issue #20 (strange EOF/Timeout behavior on BSD systems)

[takluyver]

But this only changes code used by interact(), right? The problem in #20 doesn't relate to interact(), so I'd be surprised if they were connected.

[jquast]

agreed, i came to the same conclusion and tabled it as "Compare and consider... later" ;-) hehe

[takluyver]

OK, but there's nothing we think we should be aiming to fix before 3.0, then? @finder , is that OK? I'm aiming to release 3.0 tomorrow if everything's clear.

[jself]

The git tip seems ok for me, I have no other complaints. :)
On Nov 10, 2013 2:49 PM, "Thomas Kluyver" notifications@github.com wrote:

OK, but there's nothing we think we should be aiming to fix before 3.0,
then? @finder https://github.com/finder , is that OK? I'm aiming to
release 3.0 tomorrow if everything's clear.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/23#issuecomment-28158707
.

[takluyver]

Great :-)

[takluyver]

@jquast I'll leave this open for you to take a look at regarding #20 - you can close it if you do decide that it's unrelated.

[jquast]

All said, I think we leave this alone for the 3.0 release, yet edit the summary of this issue and retain this bug.

What troubles me: the variable "data" is re-used, for both stdin of controlling process, and stdout of child pty, within a loop. In the case of an I/O Error reading from child process, an implicit pass occurs, and any of three conditions then occur:

1. The value of 'data' is continued from the prior loop; which, if no stdin was read, is the previously read data from the same pty -- therefor the output of the program is duplicated.
2. The value of 'data' is continued from the prior loop; which, if stdin was read, data that was previously already handled as keyboard input is now handled as keyboard output.
3. If data has not yet been defined, and an I/O Error occurs on the first assignment of it, (the first loop), then a NameError exception is raised: name 'data' is not defined.

All said -- an IO Error occurs when reading from a child pty that has exited. What we're looking to test, then, is a very brief moment of time where the child process has not yet exited (self.isalive() returns True), has data to read (fd returned in select() call), but then exits before it is read by the parent process (causing an IOError exception).

We're also looking at some very specific operating systems: In Linux, OSError raises to signal that an EOF occurred. BSD on the other hand would return an empty bytestring.

I'm going to re-name the title of this and mark it as a minor bug, as something that needs test coverage -- and fixing, if necessary. It may take some tinkering to write correct coverage for.

[jquast]

actually, will close and open a bug instead. thanks for reading :-)