running "python -i" in subprocess shows no prompt
Thanks for letting me know that the list takes no attachments.
Please find my modified code at the end of this email. I found one problem. I was reading streams with "proc.stderr.readline()", which never returned, because only ">>> " was sent to stderr repeatedly, "\n" only going to stdout.
Now I am using proc.stderr.read(1) instead, and I do receive the prompts. Unfortunately both streams are mixed up:
Python 2.7.15rc1 (default, Nov 12 2018, 14:31:15)
[GCC 7.3.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 1>>> 6
I found that the pty module might be a solution, also from the helpful comments in this thread, but I can't find a simple example how to make it work.
This is my last attempt, which produced the above output:
import subprocess, threading, time, os, sys
? while cont:
??? # was: c=proc.stdout.readline()
? while cont:
??? # was: c=proc.stderr.readline()
for i in range(1,5):
? proc.stdin.write("print %d*%d\n" % (i,i))
proc.stdin.write("print\n") #make last read(1) finish
Mar 18, 2019, 6:26 PM by wlfraed at ix.netcom.com:
> On Mon, 18 Mar 2019 14:10:51 +0100 (CET), <> finnkochinski at keemail.me <mailto:finnkochinski at keemail.me>> >
> declaimed the following:
> >I try to start a separate python subprocess using the attached code. This example should catch all stdout and stderr output from the launched subprocess and send commands to its stdin.
> No attachments here... either inline the code or provide a link to some
> file server.
> >The problem is that the prompt ">>>" asking for then next input is neither sent to stdout nor to stderr. The commands sent to stdin aren't echoed to stdout either.
> The odds are very good that you are encountering the problems with
> buffered I/O streams. Such streams tend to only transfer when a) closed by
> the sending side, b) an end-of-line character sequence is sent.
> The prompt string does not have an end-of-line (it expects input to be
> on the same terminal line)... so it is being held up in a buffer waiting
> for the end-of-line.
> If you aren't encountering buffering problems, then it could be that
> the (nonvisible) code is doing read line operations, and THAT is blocking
> for an end-of-line.
> Wulfraed Dennis Lee Bieber AF6VN
> > wlfraed at ix.netcom.com <mailto:wlfraed at ix.netcom.com>> HTTP://wlfraed.home.netcom.com/
> https://mail.python.org/mailman/listinfo/python-list <https://mail.python.org/mailman/listinfo/python-list>