仅在运行脚本时中断子流程管道

时间:2019-07-08 22:18:02

标签: python subprocess broken-pipe

我正在尝试使用python测试小型服务器应用程序。该应用程序的工作方式有点像远程外壳程序-它接受输入并根据输入输出一些数据。

我最初的尝试如下:

#!/usr/bin/python3
import subprocess

nc = subprocess.Popen(['/usr/bin/ncat','127.0.0.1','9999'], stdin = 
subprocess.PIPE, stdout = subprocess.PIPE)

nc.stdin.write(b'test')

这不起作用,并告诉我:

write: Broken pipe

但是,当我在python3交互式解释器中对此进行测试时,一切似乎都工作正常:

$ /usr/bin/python3
Python 3.5.3 (default, Sep 27 2018, 17:25:39) 
[GCC 6.3.0 20170516] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess
>>> nc = subprocess.Popen(['ncat','127.0.0.1','9999'], stdin = subprocess.PIPE, stdout = subprocess.PIPE)
>>> nc.stdin.write(b'test')
4

当我在外壳中运行ncat时,它也会按预期等待输入。

那是怎么回事?交互式解释器与运行脚本有何不同?为什么会影响子流程?


一些注意事项:

  • 我不想自己使用套接字。我正在测试的服务器是通过xinetd运行的,这意味着可执行文件也可以通过直接运行它来进行测试。使用当前的解决方案,我可以将['/usr/bin/ncat','127.0.0.1','9999']更改为['./server_executable']并测试所有内容,而无需中间的网络。使用套接字,我会失去此功能。
  • 我了解pexpect,甚至考虑使用它。即使我最终不使用子流程,我也想知道这里到底发生了什么。
  • 当我将服务器可执行文件提供给Popen时,一切正常。这可能暗示ncat及其运行方式存在一些问题(不知道它是否相关,但我使用的是ncat 7.40版)。

1 个答案:

答案 0 :(得分:0)

我现在可以通过脚本使它正常工作……虽然没有在解释器中尝试:

#! /usr/bin/python3
from subprocess import Popen, PIPE


netcat = "nc 127.0.0.1 9999"

p = Popen(netcat, shell=True, stdout=PIPE, stdin=PIPE, stderr=PIPE)
stdout_data = p.communicate(input=b'hi dude')[0]

请注意,我正在进行本地回送... 2个shell之一正在运行:

netcat -l -p 9999

另一个shell用于运行python脚本。在正在收听的原始外壳中,印有“ hi dude”。操作系统是Ubuntu 18.04。我可能是错的,但是我认为如果使用子流程模块,则应该使用communication()。另外,nc和netcat是可互换的/相同的可执行文件。侦听器在脚本具有“ nc”时使用了“ netcat”。

shell1

shell2