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
>> 4
>>> 9
>>> 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.
regards
Finn
This is my last attempt, which produced the above output:
import subprocess, threading, time, os, sys
cont=True
def pyout(proc):
while cont:
c=proc.stdout.read(1)
# was: c=proc.stdout.readline()
sys.stdout.write(c)
sys.stdout.flush()
def pyerr(proc):
while cont:
c=proc.stderr.read(1)
# was: c=proc.stderr.readline()
sys.stderr.write(c)
sys.stderr.flush()
proc=subprocess.Popen(['python','-i'],
stdin=subprocess.PIPE,
stdout=subprocess.PIPE,
stderr=subprocess.PIPE
)
threading.Thread(target=pyout,args=(proc,)).start()
threading.Thread(target=pyerr,args=(proc,)).start()
for i in range(1,5):
time.sleep(1.)
proc.stdin.write("print %d*%d\n" % (i,i))
proc.stdin.flush()
time.sleep(0.1)
cont=False
proc.stdin.write("print\n") #make last read(1) finish
Mar 18, 2019, 6:26 PM by wlfr...@ix.netcom.com:
> On Mon, 18 Mar 2019 14:10:51 +0100 (CET), <> finnkochin...@keemail.me
> <mailto:finnkochin...@keemail.me>> >
> declaimed the following:
>
> >Hello,
> >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
> > wlfr...@ix.netcom.com <mailto:wlfr...@ix.netcom.com>>
> HTTP://wlfraed.home.netcom.com/
>
> --
> https://mail.python.org/mailman/listinfo/python-list
> <https://mail.python.org/mailman/listinfo/python-list>
>
--
https://mail.python.org/mailman/listinfo/python-list
