2012-04-10 3 views
0

Ich bin ein Python-Skript zu schreiben, die eine Reihe von Operationen in einer Schleife durchführt, durch subprocess Telefonieren, etwa so:unvorhersehbares Verhalten mit Python subprocess nennt

os.system('./svm_learn -z p -t 2 trial-input model') 
os.system('./svm_classify test-input model pred') 
os.system('python read-svm-rank.py') 
score = os.popen('python scorer.py -g gold-test -i out').readline() 

Wenn ich die Anrufe nacheinander einzeln machen andere in der Shell funktionieren sie gut. Aber innerhalb des Drehbuchs brechen sie immer. Ich habe die Quelle des Fehlers zurückverfolgt und es scheint, dass die Ausgabedateien gegen Ende abgeschnitten werden (was mich zu der Annahme verleitet, dass Anrufe getätigt werden, ohne dass vorherige beendet werden).

Ich versuchte mit subprocess.Popen und dann mit der Methode wait() des Popen-Objekts, aber ohne Erfolg. Das Skript bricht immer noch ab.

Irgendwelche Ideen, was hier vor sich geht?

+0

"os.system" und "subprocess.call" warten beide auf den Abschluss des Systemaufrufs, bevor sie zurückkehren. Wenn Sie Hilfe bei der Fehlersuche in Ihrem Programm benötigen, benötigen wir weitere Informationen. Auch 'os.system ('python read-svm-rank.py')' sieht sehr verdächtig für mich aus, wäre es möglich zu importieren, was Sie von read-svm-rank.py brauchen? –

+1

Sind Ihre Dateien zufällig auf einem Remote-Dateisystem (wie NFS)? – amcnabb

+0

Der Benutzer löste tatsächlich sein eigenes Problem und veröffentlichte seine Lösung als Kommentar zu einer gelöschten Antwort. Es wurde von Dateien verursacht, die nicht geschlossen wurden und daher nicht auf die Festplatte ausgeleert wurden. – agf

Antwort

0

Ich würde wahrscheinlich zuerst ein wenig umschreiben, um das Subprozessmodul anstelle des OS-Moduls zu verwenden.

Dann würde ich wahrscheinlich genau prüfen, was falsch läuft durch einen Systemaufruf Spur studieren: http://stromberg.dnsalias.org/~strombrg/debugging-with-syscall-tracers.html

Hoffentlich werde ein „E“ Fehlercode am Ende der Datei sein, dass Sie sagen, was Fehler wird angetroffen.

Eine andere Option wäre, Teilmengen Ihrer Teilprozesse zu kommentieren (vorausgesetzt, dass die n + 1 nicht stark von der Ausgabe der n-ten hängt), um festzustellen, welcher von ihnen Probleme hat. Danach können Sie einige zusätzliche Fehlerberichte in das störende Skript streuen, um zu sehen, was es tut.

Aber wenn Sie nicht von C-ish syscall Spuren verschreckt werden, könnte das einfacher sein.

+0

Der Benutzer löste tatsächlich sein eigenes Problem und veröffentlichte seine Lösung als Kommentar zu einer gelöschten Antwort. Es wurde von Dateien verursacht, die nicht geschlossen wurden und daher nicht auf die Festplatte ausgeleert wurden. – agf