Aufrufe im selben Kontext
@darktrym: was Du versuchst, ist Informationen irgendwie quer fließen zu lassen, zwischen Prozessen, die keine Beziehung zueinander haben. Üblich sind Vater-Kind-, Server-Client-, Pipeline-Beziehungen. Dafür sind auch die Kommunikationsmittel der Betriebssysteme ausgelegt. Für anderes mußt Du schon sehr viel Gewalt anwenden.
@darktrym:
Vater-Kind sollte für Linux funktionieren, heisst, Du müsstest die nachfolgenden Skripte im vorherigen aufrufen. Alternativ könntest Du Deine Zustandsvariablen des Skriptes XY auch vom Skript zurückgeben lassen (keine echte Rückgabe, eher eine Art finales Print der eigenen Variablen), um sie in der Vatershell für das nächste Skript vor Skriptstart explizit zu setzen. (Das einfache Aneinanderketten der Skripte "vergisst" die Variablen, da ein Skript diese in der eigenen Kindshell setzt und die Elternshell diese nie gesehen hat.)
Keine Ahnung, was hier unter Windows möglich ist.
Vater-Kind sollte für Linux funktionieren, heisst, Du müsstest die nachfolgenden Skripte im vorherigen aufrufen. Alternativ könntest Du Deine Zustandsvariablen des Skriptes XY auch vom Skript zurückgeben lassen (keine echte Rückgabe, eher eine Art finales Print der eigenen Variablen), um sie in der Vatershell für das nächste Skript vor Skriptstart explizit zu setzen. (Das einfache Aneinanderketten der Skripte "vergisst" die Variablen, da ein Skript diese in der eigenen Kindshell setzt und die Elternshell diese nie gesehen hat.)
Keine Ahnung, was hier unter Windows möglich ist.
1. Darum dreht sich das ganze Thema ohne eine Lösung gefunden zu haben.
2. Geht das nicht, weil man nicht an die veränderte Umgebung rankommt.
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.
2. Geht das nicht, weil man nicht an die veränderte Umgebung rankommt.
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.
@darktrym:
zu 1.)
Was spricht dagegen, das Folgeskript dem ersten zu übergeben und am Ende des ersten INNERHALB aufzurufen? Die Variablen sollten dann gesetzt sein, da eine Art "Shellabstieg" erfolgt.
zu 2.)
Wer ist man? Innerhalb des Skriptes kennst Du doch die Variablen. Diese (oder notfalls alle) könnte man durch ausgeben und von der Elternshellver arbeiten lassen.
zu 1.)
Was spricht dagegen, das Folgeskript dem ersten zu übergeben und am Ende des ersten INNERHALB aufzurufen? Die Variablen sollten dann gesetzt sein, da eine Art "Shellabstieg" erfolgt.
zu 2.)
Wer ist man? Innerhalb des Skriptes kennst Du doch die Variablen. Diese (oder notfalls alle) könnte man durch ausgeben und von der Elternshellver arbeiten lassen.
1.) Erstens ist das keine Lösung des Problems. Die Skripte und Makefiles sind bewusst getrennt wurden, die werde ich nicht unnötigerweise verknüpfen. Zwischen den Skripten kann sonst was passieren, was ich noch offen halten will. Schließlich soll auch noch der Nutzer in den Ablauf eingreifen können.
2.) Ich kenne die nicht alle und wie sie auch nicht kennenlernen, sind sicher ein paar Dutzend über mehrere Dateien verteilt mit nichttrivialer Logik verknüpft. Schon mal das Android Build System gesehen?
2.) Ich kenne die nicht alle und wie sie auch nicht kennenlernen, sind sicher ein paar Dutzend über mehrere Dateien verteilt mit nichttrivialer Logik verknüpft. Schon mal das Android Build System gesehen?
-
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.
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.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.
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.
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.
-
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.
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.
@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.
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.darktrym hat geschrieben:Wenn ich eine Shell starte dann erbt die doch ihre Umgebung. Alle nachfolgenden Änderungen geben dort mit ein.
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 