On Monday, December 30, 2013 9:09:38 AM UTC-8, Volker Braun wrote:
>
> That is exactly what I am talking about: The pexpect pattern must match at
> a point where the subprocess has stopped processing and is just waiting for
> further input. But if you match for a prompt, say, and then the subprocess
> spits out another space or return before it waits for input then the
> additional characters will end up in random places in the output stream.
>>
>>
I still have trouble fitting that diagnosis to what I observe:
Parent:
P1: write(26, "print(sage698);", 15) = 15
P2: select(0, NULL, NULL, NULL, {0, 0}) = 0 (Timeout)
P3: write(26, "\n", 1) = 1
Child:
C1: read(0, "print(sage698);\n", 1024) = 16
C2: write(1, "x2^2-x0^2", 9) = 9
C3: write(1, "\n", 1) = 1
C4: write(1, "> ", 2) = 2
Parent:
P4: read(26, "print(sage698);x2^2-x0^2\r\n> \r\n", 1000) = 30
The fact that C1 ends in a newline sugggests that both P1 and P3 have
completed before C1 executes. However, P4 suggests that it is seeing the
result of
<echo of P1>, C2, C3, C4, <echo of P3>. That looks more like a race
condition between the pty echo and the output produced by the child. I
don't see how pexpect could avoid this. from happening (and it's rare
indeed).
Actually, it seems to me that the pty is being a bit careless: shouldn't it
>> make sure that it's done echoing before it actually delivers the character
>> to the process?
>>
>
> There is no such guarantee, pexpect is akin to typing into a terminal. If
> echo is on then the typed key shows up immediately and in-between stdout.
>
Hm, I've never seen a key I typed end up being echoed *after* the next
prompt had printed, and I thought this was because the prompt was printed
only *after* the input was received, hence *after* the echo had completed.
That is not quite the same scenario as two processes writing to the same
stream in an uncoordinated way.
Possibly, if we merge P1 and P3 we can significantly reduce the probability
of this happening, since then P1+P3 will arrive together at the pty, so it
has a better chance of echoing them both.
Alternatively, if we get rid of the echo altogether, then there is nothing
to have a race condition with, so this particular issue might be going away
completely.
On #15440 it also seems to be an *echoed* space that gets in the way, so it
might help there too. Preliminary tests suggest:
sage: import pexpect
sage: child=pexpect.spawn("maxima")
sage: child.expect("(%i.*) ")
0
sage: child.sendline("1+2;")
5
sage: child.readline()
'1+2;\r\n'
sage: child.readline()
'(%o1) 3\r\n'
whereas with echo turned off:
sage: import pexpect
sage: child=pexpect.spawn("maxima")
sage: child.setecho(0)
sage: child.expect("(%i.*) ")
0
sage: child.sendline("1+2;")
5
sage: child.readline()
'(%o1) 3\r\n'
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.
