Seite 2 von 2
Re: Aufrufe im selben Kontext
Verfasst: Freitag 28. März 2014, 11:20
von BlackJack
@darktrym: Ich würde sagen das was Du machen willst geht nicht. Zumindest nicht unter Unix/Linux. Du bräuchtest ja vom Elternprozess aus die Umgebungsvariablen des Kindprozesses nach dem es beendet ist, um sie dem nächsten Kindprozess zu geben. Nur ist die Umgebung weg wenn ein Prozess beendet ist.
Re: Aufrufe im selben Kontext
Verfasst: Freitag 28. März 2014, 11:26
von snafu
darktrym hat geschrieben:Die Lösung die im Netz herumgeistert ist via
Popen und und communicate. Nur scheints mit cmd nicht zu funktionieren. Von Pipe geschlossen bis Lesefehler alles mögliche nur nicht das Gewollte.
Die im Link vorgeschlagenen Lösungen verhalten sich wie eine Pipe. Du kannst durch eine Pipe aber keine Informationen über den Zustand von Umgebungsvariablen schicken. Über Pipes werden nur die Ein- bzw Ausgänge von Streams miteinander verbunden. Da geht es also um die Programmausgabe, die du andernfalls ja in deiner Shell sehen würdest. Vergiss das mit den Pipes einfach in Bezug auf dein Problem.
Re: Aufrufe im selben Kontext
Verfasst: Freitag 28. März 2014, 11:31
von darktrym
Brauch ich auch nicht. Wenn ich eine Shell starte dann erbt die doch ihre Umgebung. Alle nachfolgenden Änderungen geben dort mit ein.
In meinem Beispiel würde ich cmd starten und die Aufrufe(inkl. Parameter) pipen. Leider klappt es nicht weil Python direkt nach dem communicate die Pipe dicht macht.
Re: Aufrufe im selben Kontext
Verfasst: Freitag 28. März 2014, 11:58
von BlackJack
@darktrym: Wenn Du die Shell „fernsteuern” möchtest, dann geht das einfach nur mit Pipes nicht, weil das Kommunikationsverhalten abhängig davon ist ob die andere Seite einer Verbindung ein Terminal ist oder nicht. Du müsstest der anderen Seite vortäuschen Dein Prozess ist ein Terminal. Das `pexpect`-Modul macht so etwas zum Beispiel.
Aber selbst das dürfte Dein Problem nicht lösen, denn wenn Du die Shell fernsteuerst und dort ein Skript startest, ist nach dessen Abarbeitung die Umgebung ja auch weg und für das nächste Skript nicht verfügbar.
Du könntest in der Shell die Skripte höchstens „sourcen” — dann darf aber in keinem der Skripte so etwas wie ``exit`` benutzt werden, denn das würde die Shell beenden und man könnte kein Folgeskript mehr starten/„sourcen”.
Das was Du möchtest ist einfach nicht vorgesehen.
Re: Aufrufe im selben Kontext
Verfasst: Freitag 28. März 2014, 11:59
von Sirius3
@darktrym: das funktioniert nicht wie Du Dir das vorstellst. Wenn die Pipe erstellt wird, sind die Prozesse ja schon getrennt. Ein Ändern der Umgebung im einen Prozess hat (zum Glück) keine Auswirkung auf den anderen. Ein sauberer Weg wäre, dass Skript A ein Skript erstellt, das die Variablen setzt und dann Skript B aufruft. Damit wird auch klar, welche Parameter von A nach B wandern.
Re: Aufrufe im selben Kontext
Verfasst: Freitag 28. März 2014, 12:31
von snafu
darktrym hat geschrieben:Wenn ich eine Shell starte dann erbt die doch ihre Umgebung. Alle nachfolgenden Änderungen geben dort mit ein.
Ja, aber doch nur in vertikaler Hinsicht (=Skript startet Subshell). Du aber willst ja offenbar die einzelnen Aufrufe unabhängig voneinander machen. Wenn du zuerst Programmaufruf A machst und dann unabhängig davon Programmaufruf B, dann hast du - wie schon erwähnt wurde - 2 Shells benutzt, die nichts voneinander wissen. Wenn du das zentral steuern möchtest, dann kannst du eigentlich nur ein "Mutter-Skript" als Krücke benutzen. Ein direktes Auslesen der Umgebungsvariablen "von außerhalb" geht AFAIK nicht. Höchstens über "export" und anschließendem Parsen der Ausgabe. Das ist aber sehr unschön, weil nicht plattformübergreifend und weil das mit anderen Programmausgaben vermischt werden könnte. Was wohl ginge, wäre die Umleitung vom "export"-Output in eine Datei, die ein anderer Prozess dann wieder lesen und z.B. in eine Python-`dict` parsen müsste. Alles recht umständlich.
Re: Aufrufe im selben Kontext
Verfasst: Freitag 28. März 2014, 13:01
von jerch
Unter Linux dürfte selbst der pexpect/pty-Trick nicht weiterhelfen, da der Zeitpunkt des Prozessendes und Verwerfen von ENV nicht klar ist. Einzige Abhilfe, die ich da sehe, wäre ein Kernelmodul, welches vor Aufräumen des Prozesses ENV irgendwohin ausgibt. Definitiv zuviel des Guten
