2011-11-10 14 views
14

Tengo un problema al usar el subproceso.Popen o subprocess.call cuando los uso para ejecutar líneas de comando que generan una gran cantidad de salida, los scripts Python se cuelgan, pero ¿qué es? raro que después de esperar un rato, mientras que el guión está en su estado colgando, me parece que el trabajo ordenado por la línea cmd se ha hecho, y sólo el guión está colgado.Python: subproceso.Popen y subprocess.call hang

subprocess.call(cmd, shell = True) 
#OR 
subprocess.Popen(cmd, stdout = subprocess.PIPE, stdin = subprocess.PIPE, shell = True) 
# HANGS HERE 
print "show something after subprocess" 

Tenga en cuenta que la última impresión nunca se ejecuta, pero en realidad el cmd se ha ejecutado.

Tenga en cuenta también el cmd está relacionado con el puerto serie, por lo que cuando conecto el cable serie, todo se convierta en bien, y la última impresión statetement conseguir ejecutado. Pero cuando uso el terminal todo está bien, incluso si el serial está conectado, solo ocurre con el script de python.

Muchas gracias

Respuesta

12

De acuerdo con la documentación de Python, subprocess.call ejecuta el comando y espera a que se complete, lo que es equivalente a subprocess.Popen seguido por Popen.wait.

Sin embargo, la documentación del método Popen.wait advierte explícitamente sobre el problema del desbordamiento del búfer y recomienda usar Popen.communicate en su lugar. Por lo tanto, la solución que está buscando debe ser algo como:

import subprocess 
process = subprocess.Popen(cmd, stdout=subprocess.PIPE, stdin=subprocess.PIPE, shell=True) 
stdout, stderr = process.communicate() 
print "show something after subprocess" 
+1

No hay ningún problema usando 'subprocess.call' si usted no usa' subprocess.PIPE', que el PO no lo es. – interjay

+1

No explica por qué el resultado de la instrucción 'print' no se muestra en el elemento principal. 'Popen()' no espera al hijo, incluso si el proceso hijo está bloqueado en un intento de escribir en el conducto con el búfer completo. – jfs

2

No entiendo por qué su primera línea no funciona - ya que no hay stdin/stdout/stderr redirecciones, no hay necesidad para bloquear

El segundo uno se supone para bloquear si el proceso

  1. espera datos a través de la entrada estándar o
  2. envía más datos para la salida estándar de un tubo puede contener wothout que se lee.

Pero como su subproceso termina correctamente, no veo razón para bloquearlo también. ¿Estás seguro de que realmente termina?

Cuestiones relacionadas