Aber ich denke der Aufbau ist eher so:
Code: Alles auswählen
myProcess = subprocess.Popen('test.exe')
myProcess.terminate()
Code: Alles auswählen
myProcess = subprocess.Popen('test.exe')
myProcess.terminate()
Standardmäßig nicht.azami1986 hat geschrieben:Hallo Leute,
wisst ihr vielleucht wie man einen Prozess, der mit subprocess gestartet wurde in python abbrechen kann? Gibt es einen Kill befehl oder ähnlich?
Hab in der API nichts gefunden...
Wäre sehr dankbar, wenn da jemand was wüsste...
Ups, ja.jens hat geschrieben:Sieht spontan nach linux-only ausQubit hat geschrieben:Aber schau dir mal die proctools von pycopia an
Weil diese Funktionalität auf Windows-Systemen nicht existiert. "os.kill()" ist – trotz seines Namens – keine Funktion zum Töten von Prozessen, sondern lediglich zum Senden von Signalen. Man mittels os.kill auch ganz andere Dinge vollführen, wie z.B. per "os.kill(pid, signal.SIGUSR1)" Dienste dazu bewegen, ihre Konfiguration neu einzulesen oder per "os.kill(pid, signal.SIGSTOP)" Prozesse anhalten.jens hat geschrieben:os.kill() wird unter Windows nicht unterstützt. Warum eigentlich nicht?
Richtig, aber das muss es auch nicht. Wie man an ``subprocess.Popen.kill()`` sieht ist das unter Windows identisch mit ``subprocess.Popen.kill()``. Da trifft meiner Meinung nach Although practicality beats purity. aus dem Zen ein. Es spräche ja nichts dagegen unter Windows in ``os.kill`` nur die Signale 15 und 9 zuzulassen und beide ``TerminateProcess`` ausführen zu lassen.lunar hat geschrieben:Deswegen kann man "os.kill" zumindest in seiner derzeitigen Semantik nicht plattformübergreifend implementieren, da etwas wie "os.kill(pid, 17)" unter Windows überhaupt nicht definiert ist.
Dagegen spräche imho, dass sich dem Semantik der Funktion dann zwischen beiden Systemen unterscheiden. Ich fände es besser, eine zweite Funktion "os.terminate(pid)" einzuführen, die speziell dafür da ist, plattformübergreifend Prozesse zu töten.Leonidas hat geschrieben:Richtig, aber das muss es auch nicht. Wie man an ``subprocess.Popen.kill()`` sieht ist das unter Windows identisch mit ``subprocess.Popen.kill()``. Da trifft meiner Meinung nach Although practicality beats purity. aus dem Zen ein. Es spräche ja nichts dagegen unter Windows in ``os.kill`` nur die Signale 15 und 9 zuzulassen und beide ``TerminateProcess`` ausführen zu lassen.lunar hat geschrieben:Deswegen kann man "os.kill" zumindest in seiner derzeitigen Semantik nicht plattformübergreifend implementieren, da etwas wie "os.kill(pid, 17)" unter Windows überhaupt nicht definiert ist.
``subprocess.Popen.kill()`` unterscheidet sich jetzt schon von der Semantik unter den Systemen. Kleine semantische Unterschiede sind IMHO weniger störend als komplett fehlende Unterstützung von ähnlichen Features unter verschiedenen Platformen.lunar hat geschrieben:Dagegen spräche imho, dass sich dem Semantik der Funktion dann zwischen beiden Systemen unterscheiden. Ich fände es besser, eine zweite Funktion "os.terminate(pid)" einzuführen, die speziell dafür da ist, plattformübergreifend Prozesse zu töten.
kill(), die gebräuchlichen Signale und die Programme zur Prozessverwaltung (e.g. ps) sind POSIX-Standard. Die Prozessverwaltung läuft unter allen Unix-Derivaten weitgehend identisch, wenn man sich auf die Grundfunktionen beschränkt. Auf Sonderfunktionen wie /proc darf man sich natürlich nicht verlassen.Leonidas hat geschrieben:Die Prozessverwaltungen unterscheiden sich AFAIR sogar unter den Unices, also wäre es der Argumentation nach auch sinnlos ``os.kill()`` überhaupt bereitzustellen.
Python bietet aber auch keine Unix-only Variante die Ausgabe von ``ps`` zu parsen, ebensowenig wie es dies für Windows bietet. Also muss man so oder so, auf platformspezifische Weise eine PID bekommen (sofern man den Subprocess nicht selbst gestartet hat, aber das wird inzwischen von ``subprocess`` abgedeckt) und nun muss man diese PID wiederrum auf platformspezifische Weise an eine Funktion zum Beenden weitergeben, weil ``os.kill()`` unbedingt die komplette POSIX-Semantik wiederspiegeln muss obwohl gleich daneben, in ``subprocess`` diese Semantik nicht streng eingehalten wird?lunar hat geschrieben:kill(), die gebräuchlichen Signale und die Programme zur Prozessverwaltung (e.g. ps) sind POSIX-Standard.
Es soll eben für Betriebsysteme die es voll unterstützen das machen was es jetzt tut, auf anderen Systemen eben in dem Umfang wie es vom OS unterstützt wird. Also bei Windows eben ``TerminateProcess``.lunar hat geschrieben:Und wenn os.kill nicht die POSIX-Semantik wiederspiegeln soll, wie sollte es dann deiner Meinung nach aussehen? Windows kennt ja nicht mal PIDs.
Es geht nicht um das Senden von Signalen sondern um das Terminieren von Applikationen. Natürlich ist erreicht man das Terminieren durch SIGTERM und SIGKILL, aber als User ist es mir *egal*. Ich will eine Applikation deren PID ich kenne beenden. Das geht unter Unices mit ``os.kill``, unter Windows nicht. Es wäre bereits genug wenn ``os.kill`` unter Windows nur SIGTERM/SIGKILL durch ``TerminateProcess`` unterstützen würde, das sind wohl auch unter Unix das Signal, das am häufigsten verwendet wird.lunar hat geschrieben:Im Übrigen hat subprocess.Popen.kill genau gar nichts mit os.kill zu tun, wenn schon, dann wäre die entsprechende Funktion subprocess.Popen.send_signal.
Nein, aber Leute updaten und dann sind entsprechende Programme verfügbar. Oder man liefert eben sowas mit, bzw. hackt sich sowas selbst, evtl. mittels ctypes/pywin32. Aber dann muss man nur die Prozessinformation platformabhängig haben, das killen der Prozesse kann dann einheitlich geschehen. Ich ärgere mich lieber einmal mit der Win32-API als zweimal.lunar hat geschrieben:Ich bleibe dabei, dass kill() ohne eine vernünftige Möglichkeit, mit Bordmitteln Prozesse zu identifizieren, nutzlos ist. Unter Linux/Unix kann ich das mittels "ps", unter Windows gibt es nichts vergleichbares in allen Versionen.
Was ja gar kein Problem ist, die zu bekommen. So gesehen kannst du PIDs als Kompatibilitätsabstraktion ansehen.lunar hat geschrieben:Im Übrigen existieren PIDs unter Windows zwar, entsprechend aber nicht den Linux PIDs, da man sie nicht direkt als Argument in der WinAPI einsetzen kann. Man benötigt immer zwangsläufig ein Handle auf den entsprechenden Prozess.
tasklist, pslist oder look here.lunar hat geschrieben:Sorry, mir wird das blöd, denn deine Argumentation trifft geht an einer Wirklichkeit vorbei, in der man die PIDs des Prozesses, denn man töten möchte, bei der Programmierung nicht kennen kann, zugleich aber keine Möglichkeit hat, mit Bordmitteln unter Windows die PIDs bestimmter Prozesse herauszufinden. Woher soll diese PID denn kommen, die du da an os.kill weitergeben möchtest?
Hm, übersehe ich jetzt etwas?lunar hat geschrieben:Woher soll diese PID denn kommen, die du da an os.kill weitergeben möchtest?
Code: Alles auswählen
p = subprocess.Popen(
["ping","-n","100","127.0.0.1"],
shell=False
)
print "PID:",p.pid
time.sleep(10)
print "terminate?"
p2= subprocess.Popen(
["taskkill","/PID",str(p.pid)],
shell=True
)
Okay, hatte etwas Zeit mich damit zu beschäftigen (Win Vista)Qubit hat geschrieben:Ups, ja.jens hat geschrieben:Sieht spontan nach linux-only ausQubit hat geschrieben:Aber schau dir mal die proctools von pycopia an
Man sollte Windows abschaffen
wie schauts denn mit
import _subprocess
_subprocess.TerminateProcess(..)
aus?
Hat jemand damit unter Windows Erfahrung?
Code: Alles auswählen
import subprocess, _subprocess
p = subprocess.Popen(
["ping","-n","100","127.0.0.1"],
shell=False
)
time.sleep(10)
print "terminate process:",p.pid
_subprocess.TerminateProcess(p._handle,1)