Seite 1 von 2

Verfasst: Mittwoch 18. Januar 2006, 12:13
von modelnine
Möglichkeit 1 ist das richtige. ;-)

Die Dokumentation vom subprocess-Modul müßte den Rest erklären.

--- Heiko.

Verfasst: Mittwoch 18. Januar 2006, 22:10
von snakeseven
modelnine hat geschrieben:Möglichkeit 1 ist das richtige. ;-)
--- Heiko.
Ahhh ! Bin ich ja doch schonmal ein bischen weiter :D
Dennoch verstehe ich dann nicht, wieso mir dieses Minibeispiel

Code: Alles auswählen

#Daten an Subprozess schicken
import subprocess
p = subprocess.Popen('C:/Ablage/Python/PythonScripte/test.py',stdin = subprocess.PIPE)
raus = "10" + "20" + "Fred vom Jupiter"
p.stdin.write(raus)
p.close()
folgende Fehlermeldungen erzeugt:

Code: Alles auswählen

Traceback (most recent call last):
  File "C:\Ablage\Python\PythonScripte\test2.py", line 3, in -toplevel-
    p = subprocess.Popen('C:/Ablage/Python/PythonScripte/test.py',stdin = subprocess.PIPE)
  File "C:\Programme\Python24\lib\subprocess.py", line 533, in __init__
    (p2cread, p2cwrite,
  File "C:\Programme\Python24\lib\subprocess.py", line 607, in _get_handles
    c2pwrite = self._make_inheritable(c2pwrite)
  File "C:\Programme\Python24\lib\subprocess.py", line 634, in _make_inheritable
    DUPLICATE_SAME_ACCESS)
WindowsError: [Errno 6] Das Handle ist ungültig
Und dieses Beispiel bemängelt der Interpreter auch:

Code: Alles auswählen

#übergebene Daten auslesen
import sys
print sys.stdout.read()

Code: Alles auswählen

Traceback (most recent call last):
  File "C:\Ablage\Python\PythonScripte\test.py", line 2, in -toplevel-
    print sys.stdout.read()
AttributeError: read
Gruss, Seven

Verfasst: Donnerstag 19. Januar 2006, 07:38
von jens
So geht's:
test.py

Code: Alles auswählen

import subprocess

p = subprocess.Popen("python test2.py", stdin = subprocess.PIPE)
p.stdin.write("Fred vom Jupiter")
p.stdin.close()

print "ende"
test2.py

Code: Alles auswählen

import sys

print "OK1"
print "XXX%sXXX" % sys.stdin.readline()
print "OK2"
Allerdings ist das bei mir eine wackelige Geschichte... Wenn ich es in Scite Teste, dann muß bei test.py das print "ende" drin sein. Wenn ich das auskommentiere, geht es mal und dann wieder nicht...
Wenn ich es auf der Eingabeaufforderung teste, dann muß ich immer zum Schluß ein Enter drücken, damit der Interpreter beendet wird... Ich habe es auch mal versucht, vor dem p.stdin.close() ein p.stdin.write(os.linesep) einzufügen, damit readline() auf jeden Fall "weiter" macht. Das Ergebniss ist das selbe...

Und das bringt auch nichts:

test2.py

Code: Alles auswählen

import sys

print "OK"
while 1:
    line = sys.stdin.readline()
    if not line:
        break
    print line
print "OK2"

Verfasst: Donnerstag 19. Januar 2006, 09:06
von snakeseven
@ Jens: Danke dir, werds gleich mal checken.

@ Gerold: Kannst du mir noch sagen, wieso in
deinem Beispiel cPickle.dumps (mit's') verwendet wird ? Habe dazu auch bei Google nichts gefunden und in der Python Referenz, wie leider so oft, auch nichts.

Gruss, Seven

Verfasst: Donnerstag 19. Januar 2006, 09:31
von gerold
snakeseven hat geschrieben:@ Gerold: Kannst du mir noch sagen, wieso in
deinem Beispiel cPickle.dumps (mit's') verwendet wird ? Habe dazu auch bei Google nichts gefunden und in der Python Referenz, wie leider so oft, auch nichts.
Hi Seven!

Da ich davon gehört habe, dass unter Windows das Zielprogramm abgebrochen wird, wenn über sys.stdin des Zielprogramms der String "\x1a" geleitet wird, dachte ich mir, dass es besser sei, keine binären Daten über STDIN zu jagen. Da in der Erklärung von "cPicle.dumps" steht, dass damit ein String erzeugt wird, dachte ich mir, dass "dumps" sich schon darum kümmern wird, dass kein "EOF" (="\x1a") mitten im String auftauchen wird. Aber wahrscheinlich wird "dumps" exakt den gleichen Code erzeugen, wie ihn "dump" erzeugt.

Der einzige Unterschied wird also sein, dass ich vorher einen String erzeuge und diesen mit "write()" über die Leitung jage und in der Version von modelnine wird dieser Schritt ausgelassen, da "dump" sich schon darum kümmert, dass die Daten in das "File"-Objekt (in diesem Fall: STDIN des Kindprozesses) geschrieben wird.

http://python.org/doc/2.4.2/lib/node65.html

Das "BIN"-Problem besteht aber trotzdem noch, da ich ja beim "dumps" als Protokoll die Zahl 2 angegeben habe. Das war evt. nicht so gut. Hätte ich das nicht angegeben, dann würde mit Sicherheit ein "ASCII"-String generiert werden. Andererseits glaube ich nicht, dass mit "Pickle" etwas generiert wird, was den Datenfluss abbrechen könnte.

http://www.python-forum.de/viewtopic.php?p=29095#29095

lg
Gerold
:-)

Verfasst: Donnerstag 19. Januar 2006, 09:35
von jens
gerold hat geschrieben:Da ich davon gehört habe, dass unter Windows das Zielprogramm abgebrochen wird, wenn über sys.stdin des Zielprogramms der String "\x1a" geleitet wird
Das könnte man allerdings ganz einfach umgehen, wenn man vor dem Senden ein string_escape macht!

Komischerweise, bleibt aber mein beschriebenes Problem bestehen, wenn man explizit als letztes ein "\x1a" sendet :)

Verfasst: Freitag 20. Januar 2006, 14:53
von Leonidas
Die Diskussion über Vor- und Nachteile der Editoren habe ich in den Thread "Freie und komerzielle Editoren" reinverschoben, da der Thread sich selbstständig gemacht hat :wink:

Verfasst: Freitag 20. Januar 2006, 15:31
von snakeseven
Hi Gerold,
dein Sender-Empfänger Beispiel erzeugt in WingIDE folgende Exceptions:

Code: Alles auswählen

WindowsError: (193, '%1 ist keine zul\xe4ssige Win32-Anwendung')

Rückverfolgung (innerste zuletzt):

Datei "C:\Ablage\Python\PythonScripte\sender.py", Zeile 1, in ?
  #!/usr/bin/env python
Datei "C:\Ablage\Python\PythonScripte\sender.py", Zeile 54, in ?
  main()
Datei "C:\Ablage\Python\PythonScripte\sender.py", Zeile 38, in main
  cwd = os.curdir
Datei "C:\Programme\Python24\Lib\subprocess.py", Zeile 542, in __init__
  errread, errwrite)
Datei "C:\Programme\Python24\Lib\subprocess.py", Zeile 706, in _execute_child
  startupinfo)
Als nächstes werde ich es mal mit Active Python probieren. So als letzter Versuch sozusagen.

Gruss, Seven

Verfasst: Freitag 20. Januar 2006, 16:16
von gerold
snakeseven hat geschrieben:Als nächstes werde ich es mal mit Active Python probieren. So als letzter Versuch sozusagen.
Hi Seven!

Blöde Frage, aber stimmt bei dir der Pfad zu Python mit dem im Skript überein? Befindet sich "sender.py" im gleichen Ordner wie "empfaenger.py" und rufst du das Skript von dort aus auf? Funktioniert das Skript beim Aufruf von der Kommandozeile aus? Dieses Skript wurde mit WingIDE geschrieben. Es sollte also ziemlich sicher darin auch aufrufbar sein. :?

Code: Alles auswählen

    # Prozess aufrufen
    proc = subprocess.Popen(
        #Linux: ("/usr/bin/python", "empfaenger.py",),
        (r"C:\Python24\python.exe", "empfaenger.py"),
        stdin = subprocess.PIPE,
        stdout = subprocess.PIPE,
        cwd = os.curdir
    )
lg
Gerold
:-)

Verfasst: Freitag 20. Januar 2006, 16:32
von maguma :D
hallo,

wenn ich mir recht erinnere müsste das unter windows auch so gehen!

Code: Alles auswählen

# Prozess aufrufen 
    proc = subprocess.Popen( 
        #Linux: ("/usr/bin/python", "empfaenger.py",), 
        (r"/Python24/python.exe", "empfaenger.py"), 
        stdin = subprocess.PIPE, 
        stdout = subprocess.PIPE, 
        cwd = os.curdir 
    ) 
ist nur ein gedanke nichts weiteres.

Verfasst: Freitag 20. Januar 2006, 16:48
von gerold
maguma :D hat geschrieben:wenn ich mir recht erinnere müsste das unter windows auch so gehen!

Code: Alles auswählen

        (r"/Python24/python.exe", "empfaenger.py"), 
Hi!

Ja das könnte funktionieren, vorausgesetzt Python befindet sich auf dem gleichen Laufwerk wie das auszuführende Programm. Habe jetzt aber keine Lust, zu testen, ob nicht doch zumindest der Laufwerksbuchstabe angegeben werden muss. Das mit den Slash statt dem Backslash funktioniert sicher.

Aber wie ich gerade sehe, sucht Python "subprocess.py" im Ordner "C:\Programme\Python24\Lib". Dann dürfte Python bei Seven auch dort zu finden sein. Zumindest einen Ordner höher.

Code: Alles auswählen

Datei "C:\Programme\Python24\Lib\subprocess.py", Zeile 706, in _execute_child
  startupinfo)
mfg
Gerold
:-)

Verfasst: Freitag 20. Januar 2006, 17:17
von gerold
Hi Seven!

Ich habe mein Beispiel verbessert. Jetzt funktioniert es, auch wenn dein Python ganz wo anders versteckt ist.

Code: Alles auswählen

    # Prozess aufrufen
    proc = subprocess.Popen(
        (sys.executable, "empfaenger.py"),
        stdin = subprocess.PIPE,
        stdout = subprocess.PIPE,
        cwd = os.curdir
    )
Man beachte "sys.executable".

lg
Gerold
:-)

Verfasst: Freitag 20. Januar 2006, 18:55
von snakeseven
Ja, VIELEN DANK !!
So funktionierts und so kann ich das jetzt in mein Script einbauen. Wieder ein Festplattenzugriff weniger :) Darf ich fragen, wie du auf "sys.executable" gekommen bist ? Nur so zum Nachlesen, um zu kapieren, was es macht.

Grüße, Seven

Verfasst: Freitag 20. Januar 2006, 19:14
von Leonidas
snakeseven hat geschrieben:Darf ich fragen, wie du auf "sys.executable" gekommen bist ? Nur so zum Nachlesen, um zu kapieren, was es macht.
Zum nachlesen gibts die Dokumentation des sys-Moduls :wink:

In der stdlib findet man doch immer wieder neue Sachen, auch wenn man Python schon lange nutzt, so ist das eben.

Verfasst: Freitag 20. Januar 2006, 19:16
von gerold
snakeseven hat geschrieben:Darf ich fragen, wie du auf "sys.executable" gekommen bist ? Nur so zum Nachlesen, um zu kapieren, was es macht.
Hi Seven!

Das war reine Intuition. Zuerst dachte ich mir, ich müsse die Registry auslesen um zum Pfad zu Python zu kommen. Dann überlegte ich mir, dass es ja auch genügen würde, wenn ich ein Modul imporiere, das immer im Python-Ordner liegt. Also probierte ich "import os; print os.__file__" aus. Dann hätte ich nur mehr den Pfad kürzen und je nach Betriebssystem "python" oder "python.exe" ran hängen müssen.

Während dieses Denkprozesses dachte ich mir aber, dass es doch sicher noch einen einfacheren Weg geben müsse. So bin ich auf "sys" gekommen. Mit "sys.path" komme ich an die Pfade, die von Python bei der Suche nach Modulen durchgesehen werden. Mit "sys.platform" kriege ich raus, ob das Python-Programm unter Windows oder einem anderen System läuft. Also dachte ich mir, dass "sys" der richtige Platz wäre, auch einen Hinweis auf die Executable von Python zu hinterlegen.

Mal schnell wieder "ipython" gestartet und sys importiert. Dann "sys." eingeben und die Tabulatortaste gedrückt. Schon kommt mir das Wort "executable" entgegen. Ein kurzes "sys.executable" zum Ausprobieren ob das den Pfad zur Python-Exe zurück gibt -- das wars.

Manchmal kommt man über zwanzig Ecken doch noch zum richtigen Ergebnis. :o

Zum schnellen Nachlesen nehme ich meist, wenn ich unter Windows arbeite, die CHM-Hilfe-Datei. Index --> Wort eingeben --> gefunden.

Brauche ich es nicht so ausführlich, oder will ich auch noch schnell etwas testen, starte ich "ipython" (mit Readlinesupport).

lg
Gerold
:-)

Verfasst: Freitag 20. Januar 2006, 21:36
von jens
Jep, die CHM-Hilfe-Datei nutzte ich auch sehr oft... Die Referenz als PDF ist auch ok, aber langsamer...

Verfasst: Dienstag 24. Januar 2006, 14:50
von snakeseven
Hallo,
also im Interpreter funktioniert das mit der Datenübergabe, aber wenn
ich das Script mit Py2exe ausführbar mache, dann bekomme ich nachfolgende Fehlermeldungen. Habe als Kommentar daneben geschrieben, was in den betreffenden Programmzeilen steht.
Ohne ...,stdin=subprocess.PIPE) läuft auch die Py2exe Version, aber
dann habe ich ja keine Datenübergabe. Die Fehler in 'subprocess.pyc'
verstehe ich nicht. Habe mir die .pcy angesehen, aber da stehen nur Hyroglyphen drin und außerdem hat die subprocess.pyc im 'dist' Ordner nur 605 Zeilen. Hat einer ne Idee ??

Gruss, Seven

Code: Alles auswählen

---------------------------------------------------------------------
Traceback (most recent call last):
  File "Modul_Handler.py", line 434, in ?  '		# Lookat() = Hauptfunktion (Loop)
  File "Modul_Handler.py", line 174, in Lookat	# init_proz1() (s.u.)
  File "Modul_Handler.py", line 71, in init_proz1	# gv.pz1 = subprocess.Popen('... Modul_1.exe',stdin = subprocess.PIPE)
  File "subprocess.pyc", line 533, in __init__
  File "subprocess.pyc", line 607, in _get_handles
  File "subprocess.pyc", line 634, in _make_inheritable
WindowsError: [Errno 6] Das Handle ist ungültig
---------------------------------------------------------------------

Code: Alles auswählen

def init_proz1(event=None):
    gv.neustart1 = True
    gv.neust1 = 0
    if gv.pz1.poll() == 0:
        gv.pz1 = subprocess.Popen('... Modul_1.exe',stdin = subprocess.PIPE)
    else:
        kill(gv.pz1.pid)
        gv.pz1 = subprocess.Popen('... Modul_1.exe',stdin = subprocess.PIPE)

def kill(pid):
    handle = win32api.OpenProcess(1, 0, pid)
    return (0 != win32api.TerminateProcess(handle, 0))

Verfasst: Dienstag 24. Januar 2006, 15:26
von jens
Du hast den anderen Thread http://www.python-forum.de/viewtopic.php?t=4941 verfolgt, oder?

Was hast du überhaupt vor??? Lagerst du Teile deines Programms aus und machst mit py2exe daraus Ausführbare Dateien??? Das ist sicherlich nicht der optimale Weg...

Verfasst: Dienstag 24. Januar 2006, 17:08
von snakeseven
jens hat geschrieben:Du hast den anderen Thread http://www.python-forum.de/viewtopic.php?t=4941 verfolgt, oder?

Was hast du überhaupt vor??? Lagerst du Teile deines Programms aus und machst mit py2exe daraus Ausführbare Dateien??? Das ist sicherlich nicht der optimale Weg...
@1)Ich sehe in dem zitierten Thread nicht die Antwort auf mein Problem. Sollte cPickle dran schuld sein ?

@2)Ich weiss, dass viele hier die Importmethode favorisieren, ich arbeite aber aus gutem Grund mit parallel laufenden Modulen. Die Module müssen wirklich parallel arbeiten und wenn ein Fehler auftritt, beendet der Modul-Handler nur dieses eine Modul und startet es neu. Tritt der Fehler wiederholt auf, wird es ganz gestopt und der Support benachrichtigt. Die einzelnen Module rufen ihrerseits wieder Subprozesse auf, z.B. Lame ode eine Audiobearbeitungssoftware für aufwendige Effekte. Das ganze ist eine Art Miniserver für Audiobearbeitung / Konvertierung etc.. Läuft unter Zope und bis auf die neuen Fehlermeldungen läuft alles rund, inklusive ErrorLogs und Tages-, Wochen-, und Monatsprotokollen als Excel-Tabellen.

Gruss, Seven

Verfasst: Dienstag 24. Januar 2006, 17:24
von modelnine
Versuch mal zusätzlich zum stdin=subprocess.PIPE "stdout=subprocess.PIPE" und "stderr=subprocess.PIPE" mit reinzusetzen. Ich könnte mir vorstellen dass py2exe keine vernünftigen Deskriptoren für stdout und stderr zur Verfügung stellt die dupliziert werden könnten...

Ganz davon abgesehen: die Fehlermeldung bezieht sich auf die Zeile in der Quelldatei von subprocess.pyc, also subprocess.py. Da ist rund um die angegenenen Zeilen folgende Funktionen:

Code: Alles auswählen

def _get_handles(self, stdin, stdout, stderr):
            """Construct and return tupel with IO objects:
            p2cread, p2cwrite, c2pread, c2pwrite, errread, errwrite
            """
            if stdin == None and stdout == None and stderr == None:
                return (None, None, None, None, None, None)

            p2cread, p2cwrite = None, None
            c2pread, c2pwrite = None, None
            errread, errwrite = None, None

            if stdin == None:
                p2cread = GetStdHandle(STD_INPUT_HANDLE)
            elif stdin == PIPE:
                p2cread, p2cwrite = CreatePipe(None, 0)
                # Detach and turn into fd
                p2cwrite = p2cwrite.Detach()
                p2cwrite = msvcrt.open_osfhandle(p2cwrite, 0)
            elif type(stdin) == types.IntType:
                p2cread = msvcrt.get_osfhandle(stdin)
            else:
                # Assuming file-like object
                p2cread = msvcrt.get_osfhandle(stdin.fileno())
            p2cread = self._make_inheritable(p2cread)

            if stdout == None:
                c2pwrite = GetStdHandle(STD_OUTPUT_HANDLE)
            elif stdout == PIPE:
                c2pread, c2pwrite = CreatePipe(None, 0)
                # Detach and turn into fd
                c2pread = c2pread.Detach()
                c2pread = msvcrt.open_osfhandle(c2pread, 0)
            elif type(stdout) == types.IntType:
                c2pwrite = msvcrt.get_osfhandle(stdout)
            else:
                # Assuming file-like object
                c2pwrite = msvcrt.get_osfhandle(stdout.fileno())
            c2pwrite = self._make_inheritable(c2pwrite) # Fehler hier, 607.

            if stderr == None:
                errwrite = GetStdHandle(STD_ERROR_HANDLE)
            elif stderr == PIPE:
                errread, errwrite = CreatePipe(None, 0)
                # Detach and turn into fd
                errread = errread.Detach()
                errread = msvcrt.open_osfhandle(errread, 0)
            elif stderr == STDOUT:
                errwrite = c2pwrite
            elif type(stderr) == types.IntType:
                errwrite = msvcrt.get_osfhandle(stderr)
            else:
                # Assuming file-like object
                errwrite = msvcrt.get_osfhandle(stderr.fileno())
            errwrite = self._make_inheritable(errwrite)

            return (p2cread, p2cwrite,
                    c2pread, c2pwrite,
                    errread, errwrite)

        def _make_inheritable(self, handle):
            """Return a duplicate of handle, which is inheritable"""
            return DuplicateHandle(GetCurrentProcess(), handle,
                                   GetCurrentProcess(), 0, 1,
                                   DUPLICATE_SAME_ACCESS) # Fehler hier, 634.
Schaut also ganz danach aus dass das handle von stdout nicht dupliziert werden kann. Dagegen kannst Du aber wie gesagt durch obiges was tun.

--- Heiko.