同样的问题。
原因是 - 阅读以下内容后我仍然无法使其工作:
- Real-time intercepting of stdout from another process in Python
- Intercepting stdout of a subprocess while it is running
- How do I get 'real-time' information back from a subprocess.Popen in python (2.5)
- catching stdout in realtime from subprocess
我的情况是我有一个用 C 编写的控制台应用程序,让我们以循环中的这段代码为例:
tmp = 0.0;
printf("\ninput>>");
scanf_s("%f",&tmp);
printf ("\ninput was: %f",tmp);
它不断地读取一些输入并写入一些输出。
我与之交互的 python 代码如下:
p=subprocess.Popen([path],stdout=subprocess.PIPE,stdin=subprocess.PIPE)
p.stdin.write('12345\n')
for line in p.stdout:
print(">>> " + str(line.rstrip()))
p.stdout.flush()
到目前为止,每当我读取表单 p.stdout
时,它总是等到进程终止,然后输出一个空字符串。我已经尝试了很多东西 - 但仍然是相同的结果。
我尝试过 Python 2.6 和 3.1,但版本无关紧要 - 我只需要让它在某个地方工作即可。
最佳答案
尝试向子进程写入和从管道读取是很棘手的,因为默认缓冲在两个方向上进行。在一个或另一个进程(父进程或子进程)从空缓冲区读取数据、写入已满缓冲区或在系统库刷新数据之前对等待数据的缓冲区进行阻塞读取时,非常容易出现死锁。
对于更少量的数据,Popen.communicate()
方法可能就足够了。但是,对于超过其缓冲的数据,您可能会遇到停滞的进程(类似于您已经看到的情况?)
您可能想要查找有关使用 fcntl
模块以及使一个或另一个(或两个)文件描述符成为非阻塞的详细信息。在那种情况下,当然,您必须在适当的异常处理中包装对这些文件描述符的所有读取和/或写入,以处理“EWOULDBLOCK”事件。 (我不记得为这些引发的确切 Python 异常)。
一种完全不同的方法是让您的父进程使用 select
模块和 os.fork()
... 并让子进程使用 execve ()
直接处理任何文件 dup()ing 后的目标程序。 (基本上你会重新实现 Popen()
的部分,但使用不同的父文件描述符 (PIPE) 处理。
顺便说一下,至少在 Python 的 2.5 和 2.6 标准库中,.communicate 只能处理大约 64K 的远程数据(在 Linux 和 FreeBSD 上)。这个数字可能会因各种因素而异(可能包括用于编译 Python 解释器的构建选项,或链接到它的 libc 版本)。它不仅仅受可用内存的限制(尽管 J.F. Sebastian 的断言与此相反),而是被限制为一个小得多的值。
关于python - subprocess.Popen.stdout - 实时读取标准输出(再次),我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/3140189/