capture stdout en temps réel à partir du sous-processus

Je veux subprocess.Popen()rsync.exe sous Windows et imprimer le stdout en Python.

Mon code fonctionne, mais il n'attrape pas la progression tant qu'un transfert de fichier n'est pas effectué! Je souhaite imprimer la progression de chaque fichier en temps réel.

En utilisant Python 3.1 maintenant depuis que j'ai entendu dire qu'il devrait être meilleur pour gérer les E / S.

import subprocess, time, os, sys

cmd = "rsync.exe -vaz -P source/ dest/"
p, line = True, 'start'


p = subprocess.Popen(cmd,
                     shell=True,
                     bufsize=64,
                     stdin=subprocess.PIPE,
                     stderr=subprocess.PIPE,
                     stdout=subprocess.PIPE)

for line in p.stdout:
    print(">>> " + str(line.rstrip()))
    p.stdout.flush()

Quelques règles de base pour subprocess.

• Ne jamais utiliser shell=True. Il appelle inutilement un processus shell supplémentaire pour appeler votre programme.
• Lors de l'appel de processus, les arguments sont transmis sous forme de listes. sys.argven python est une liste, tout comme argven C. Vous passez donc une liste à Popenpour appeler des sous-processus, pas une chaîne.
• Ne redirigez pas vers stderrun PIPElorsque vous ne le lisez pas.
• Ne redirigez pas stdinlorsque vous n'y écrivez pas.

Exemple:

import subprocess, time, os, sys
cmd = ["rsync.exe", "-vaz", "-P", "source/" ,"dest/"]

p = subprocess.Popen(cmd,
                     stdout=subprocess.PIPE,
                     stderr=subprocess.STDOUT)

for line in iter(p.stdout.readline, b''):
    print(">>> " + line.rstrip())

Cela dit, il est probable que rsync tamponne sa sortie lorsqu'il détecte qu'il est connecté à un tube au lieu d'un terminal. C'est le comportement par défaut - lorsqu'ils sont connectés à un tube, les programmes doivent explicitement vider stdout pour les résultats en temps réel, sinon la bibliothèque C standard sera mise en mémoire tampon.

Pour tester cela, essayez d'exécuter ceci à la place:

cmd = [sys.executable, 'test_out.py']

et créez un test_out.pyfichier avec le contenu:

import sys
import time
print ("Hello")
sys.stdout.flush()
time.sleep(10)
print ("World")

L'exécution de ce sous-processus devrait vous donner "Hello" et attendre 10 secondes avant de donner "World". Si cela se produit avec le code python ci-dessus et non avec rsync, cela signifie qu'il rsyncmet en mémoire tampon la sortie, vous n'avez donc pas de chance.

Une solution serait de se connecter directement à un pty, en utilisant quelque chose comme pexpect.

Je sais que c'est un vieux sujet, mais il y a une solution maintenant. Appelez rsync avec l'option --outbuf = L. Exemple:

cmd=['rsync', '-arzv','--backup','--outbuf=L','source/','dest']
p = subprocess.Popen(cmd,
                     stdout=subprocess.PIPE)
for line in iter(p.stdout.readline, b''):
    print '>>> {}'.format(line.rstrip())

Sous Linux, j'ai eu le même problème de se débarrasser de la mise en mémoire tampon. J'ai finalement utilisé "stdbuf -o0" (ou, unbuffer from expect) pour me débarrasser du tampon PIPE.

proc = Popen(['stdbuf', '-o0'] + cmd, stdout=PIPE, stderr=PIPE)
stdout = proc.stdout

Je pourrais alors utiliser select.select sur stdout.

Voir aussi /unix/25372/

Selon le cas d'utilisation, vous pouvez également désactiver la mise en mémoire tampon dans le sous-processus lui-même.

Si le sous-processus est un processus Python, vous pouvez le faire avant l'appel:

os.environ["PYTHONUNBUFFERED"] = "1"

Ou transmettez-le dans l' envargument à Popen.

Sinon, si vous êtes sous Linux / Unix, vous pouvez utiliser l' stdbufoutil. Par exemple, comme:

cmd = ["stdbuf", "-oL"] + cmd

Voir aussi ici à propos stdbufou d'autres options.

for line in p.stdout:
  ...

bloque toujours jusqu'au prochain saut de ligne.

Pour un comportement "en temps réel", vous devez faire quelque chose comme ceci:

while True:
  inchar = p.stdout.read(1)
  if inchar: #neither empty string nor None
    print(str(inchar), end='') #or end=None to flush immediately
  else:
    print('') #flush for implicit line-buffering
    break

La boucle while est laissée lorsque le processus enfant ferme sa sortie standard ou se termine. read()/read(-1)bloquerait jusqu'à ce que le processus fils ferme sa sortie stdout ou quitte.

Votre problème est:

for line in p.stdout:
    print(">>> " + str(line.rstrip()))
    p.stdout.flush()

l'itérateur lui-même a une mémoire tampon supplémentaire.

Essayez de faire comme ceci:

while True:
  line = p.stdout.readline()
  if not line:
     break
  print line

Vous ne pouvez pas obtenir stdout pour imprimer sans tampon sur un tube (à moins que vous ne puissiez réécrire le programme qui imprime sur stdout), voici donc ma solution:

Redirigez stdout vers sterr, qui n'est pas mis en mémoire tampon. '<cmd> 1>&2'devrait le faire. Ouvrez le processus comme suit: myproc = subprocess.Popen('<cmd> 1>&2', stderr=subprocess.PIPE)
Vous ne pouvez pas faire la distinction entre stdout ou stderr, mais vous obtenez immédiatement toutes les sorties.

J'espère que cela aidera quiconque à résoudre ce problème.

Modifiez la sortie stdout du processus rsync pour qu'elle ne soit pas tamponnée.

p = subprocess.Popen(cmd,
                     shell=True,
                     bufsize=0,  # 0=unbuffered, 1=line-buffered, else buffer-size
                     stdin=subprocess.PIPE,
                     stderr=subprocess.PIPE,
                     stdout=subprocess.PIPE)

Pour éviter la mise en cache de la sortie, vous pouvez essayer pexpect,

child = pexpect.spawn(launchcmd,args,timeout=None)
while True:
    try:
        child.expect('\n')
        print(child.before)
    except pexpect.EOF:
        break

PS : Je sais que cette question est assez ancienne, fournissant toujours la solution qui a fonctionné pour moi.

PPS : a obtenu cette réponse d'une autre question

    p = subprocess.Popen(command,
                                bufsize=0,
                                universal_newlines=True)

J'écris une interface graphique pour rsync en python, et j'ai les mêmes problèmes. Ce problème me préoccupe depuis plusieurs jours jusqu'à ce que je trouve cela dans pyDoc.

Si universal_newlines vaut True, les objets fichier stdout et stderr sont ouverts en tant que fichiers texte en mode de retours à la ligne universels. Les lignes peuvent être terminées par l'un des '\ n', la convention de fin de ligne Unix, '\ r', l'ancienne convention Macintosh ou '\ r \ n', la convention Windows. Toutes ces représentations externes sont considérées comme '\ n' par le programme Python.

Il semble que rsync affichera '\ r' lorsque la traduction est en cours.

J'ai remarqué qu'il n'est pas fait mention de l'utilisation d'un fichier temporaire comme intermédiaire. Ce qui suit permet de contourner les problèmes de mise en mémoire tampon en sortant dans un fichier temporaire et vous permet d'analyser les données provenant de rsync sans vous connecter à un pty. J'ai testé ce qui suit sur une boîte Linux, et la sortie de rsync a tendance à différer d'une plate-forme à l'autre, de sorte que les expressions régulières pour analyser la sortie peuvent varier:

import subprocess, time, tempfile, re

pipe_output, file_name = tempfile.TemporaryFile()
cmd = ["rsync", "-vaz", "-P", "/src/" ,"/dest"]

p = subprocess.Popen(cmd, stdout=pipe_output, 
                     stderr=subprocess.STDOUT)
while p.poll() is None:
    # p.poll() returns None while the program is still running
    # sleep for 1 second
    time.sleep(1)
    last_line =  open(file_name).readlines()
    # it's possible that it hasn't output yet, so continue
    if len(last_line) == 0: continue
    last_line = last_line[-1]
    # Matching to "[bytes downloaded]  number%  [speed] number:number:number"
    match_it = re.match(".* ([0-9]*)%.* ([0-9]*:[0-9]*:[0-9]*).*", last_line)
    if not match_it: continue
    # in this case, the percentage is stored in match_it.group(1), 
    # time in match_it.group(2).  We could do something with it here...

si vous exécutez quelque chose comme ça dans un thread et enregistrez la propriété ffmpeg_time dans une propriété d'une méthode afin que vous puissiez y accéder, cela fonctionnerait très bien.J'obtiens des sorties comme celle-ci: la sortie est comme si vous utilisez le threading dans tkinter

input = 'path/input_file.mp4'
output = 'path/input_file.mp4'
command = "ffmpeg -y -v quiet -stats -i \"" + str(input) + "\" -metadata title=\"@alaa_sanatisharif\" -preset ultrafast -vcodec copy -r 50 -vsync 1 -async 1 \"" + output + "\""
process = subprocess.Popen(command, stdout=subprocess.PIPE, stderr=subprocess.STDOUT, universal_newlines=True, shell=True)
for line in self.process.stdout:
    reg = re.search('\d\d:\d\d:\d\d', line)
    ffmpeg_time = reg.group(0) if reg else ''
    print(ffmpeg_time)

Dans Python 3, voici une solution, qui supprime une commande de la ligne de commande et délivre en temps réel des chaînes bien décodées à mesure qu'elles sont reçues.

Receveur (receiver.py ):

import subprocess
import sys

cmd = sys.argv[1:]
p = subprocess.Popen(cmd, stdout=subprocess.PIPE)
for line in p.stdout:
    print("received: {}".format(line.rstrip().decode("utf-8")))

Exemple de programme simple qui pourrait générer une sortie en temps réel (dummy_out.py ):

import time
import sys

for i in range(5):
    print("hello {}".format(i))
    sys.stdout.flush()  
    time.sleep(1)

Production:

$python receiver.py python dummy_out.py
received: hello 0
received: hello 1
received: hello 2
received: hello 3
received: hello 4