Yes, agree that this is slightly different.
I also agree that it would be much better if the pexpect interfaces would
have been written against non-echoing tty. Of course that'll only work if
the subprocess doesn't turn echoing back on. The downside is of course that
you have to rewrite the way the pexpect interface works.
The alternative is to get rid of pexpect altogether, and patch the
subprocess input to instead setup & read from a socket (and flush on
command). I did some work in that direction but haven't had the time to
finish it...
On Monday, December 30, 2013 7:09:19 PM UTC, Nils Bruin wrote:
>
> 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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.
