捕获未写入stdout的控制台输出,stderr?

Ube*_*per 4 python subprocess

我有一个名为pregeocode的Windows应用程序(我们缺少源代码),这个程序基本上将地理编码写入输入文件.除非出现错误,否则该程序实际上不会向控制台写入任何内容.这个程序通常从一个小的Python程序调用(它处理参数等,并进行所有有趣的预处理).

我们通过查看输出文件是否实际创建来检查它是否失败(无论如何,它总是返回0).但是当它失败时,子进程显示没有任何内容打印到stderr或stdout.(它成功地处理了大约一百个,只有一个是坏的,但我希望能够看到导致错误的原因)

小python脚本通过subprocess.Popen调用应用程序:

argslist = [r'C:\workspace\apps\pregeocode.exe', '-in', inputfilename, '-out', outputfilename, '-gcp', gcp_file]
p = subprocess.Popen(argslist, stderr=subprocess.PIPE, stdout=subprocess.PIPE)
print str(p.communicate())
Run Code Online (Sandbox Code Playgroud)

给出的输出:

('', '')
Run Code Online (Sandbox Code Playgroud)

但是,如果我通过cmd使用相同的参数手动运行程序,我得到的输出:

45 IMAGE_EXTENT_TOO_SMALL
Run Code Online (Sandbox Code Playgroud)

(有大约60多个不同的错误消息,45表示错误号)

使用shell = True参数不会改变任何东西,我也无法在网上找到关于这个问题的任何内容.实际的exe是很久以前在内部制作的东西,我们缺少它的源代码,所以我看不出它是如何打印出来的.

那么为什么子进程实际上不能捕获stdout或stderr呢?

编辑

os.system(" ".join(argslist))
Run Code Online (Sandbox Code Playgroud)

正确打印错误消息:

45 IMAGE_EXTENT_TOO_SMALL
Run Code Online (Sandbox Code Playgroud)

编辑2

原来应用程序使用ERDAS的工具包.他们的工具包将所有stdout/stderr重定向到他们的日志记录子系统.然后,日志记录子系统通过"CON"重写它.

zwo*_*wol 5

由于错误消息真的不来了在任stdoutstderr,我最好的猜测是,该程序正在使用Windows的等效断开的/dev/tty,不管它是什么.在Unix中,您可以小心使用拦截它,pty.openpty但据我所知,在Python中不支持类似Windows的特定技巧.您可以尝试使用Expect for Windows.