[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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
>> 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.


This is my last attempt, which produced the above output:

import subprocess, threading, time, os, sys


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()

? stdin=subprocess.PIPE,
? stdout=subprocess.PIPE,
? stderr=subprocess.PIPE


for i in range(1,5):
? time.sleep(1.)
? proc.stdin.write("print %d*%d\n" % (i,i))
? proc.stdin.flush()

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:
> >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
>  > 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>