Aufrufe im selben Kontext

[darktrym]

Folgendes Problem:
Ich habe eine Menge von Shellskripten und Makefiles etc. die sich gegenseitig bedingen und ihre Konfiguration überwiegend aus den Umgebungsvariablen holen. Nun würde ich gerne diese Aufrufe zentral steuern in einer Python GUI. Geht das denn?

[Sirius3]

@darktrym: das geht.

[darktrym]

Und wie? Erzeugt nicht subprocess bzw. system bei jeden Aufruf ein neues Terminal vergisst damit die gemachten Änderungen?

[Sirius3]

wie kommst Du drauf? Statt zu fragen, kannst Du es ja auch ausprobieren.

[darktrym]

Hab ich, es funktioniert mit subprocess/os.system nicht.

[Sirius3]

was hast Du probiert? Es macht die Fehlersuche erheblich einfacher, wenn Du Deinen Code postest.

[darktrym]

Code: Alles auswählen

set a=asd

Code: Alles auswählen

echo %a%

Code: Alles auswählen

import subprocess
subprocess.call(["b.bat"], shell=True)
subprocess.call(["c.bat"], shell=True)

[Leonidas]

Das startet ja zwei unterschiedliche Shells, in der esten definierst du ``a``, terminierst die, startest dann eine weitere und woher soll diese dann wissen dass ``a`` jemals definiert wurde?

[darktrym]

Ich hab auch nicht behauptet das es anders wäre.

[Sirius3]

Du hast Dir ja auch seltsame Skripte ausgedacht. Das funktioniert auch nur mit Windows. Der übliche Weg ist es, dem subprocess-Aufruf die Environmentvariablen zu übergeben und nicht zu versuchen, sie in irgendeinem anderen Batchprocess zu setzen.

Ürigens aus der Dokumentation: The only time you need to specify shell=True on Windows is when the command you wish to execute is built into the shell (e.g. dir or copy). You do not need shell=True to run a batch file or console-based executable.

[darktrym]

Mein Programm würde auf Linux laufen, hätte aber die gleichen Probleme bekommen.
Man kann ja set durch export und %a% durch $a austauschen und daraus ein Shellskript. Mit dem Shebang müsste man sich den executable Parameter sparen können. Also, gibts für diese Art von Problem eine Lösung?

[Leonidas]

Ich hab auch nicht behauptet das es anders wäre.

Und Windows-Batch-Dateien werden nicht wie Shell-Skripte unter Unix in Subshells aufgerufen? Das ist ja seltsam…

[Leonidas]

Mein Programm würde auf Linux laufen, hätte aber die gleichen Probleme bekommen.
Man kann ja set durch export und %a% durch $a austauschen und daraus ein Shellskript. Mit dem Shebang müsste man sich den executable Parameter sparen können. Also, gibts für diese Art von Problem eine Lösung?

Dein Programm hätte unter Linux auch nicht funktioniert, weil die Shellskripte auch von deiner Shell in Subshells ausgeführt worden wären. Unabhängig von Python. Damit das geht müsstest du sie mit ``source`` einbinden. Das kannst du mit Python genauso haben indem du beide Skripte hintereinander in eine Datei schreibst.

[Sirius3]

Unter Linux funktionert das nicht:

Code: Alles auswählen

~$ cat a.sh
#!/bin/bash
export a=17
echo $a
~$ cat b.sh
#!/bin/bash
echo $a
~$ ./a.sh
17
~$ ./b.sh

~$ 

Weil Linux für jedes Skript immer einen neuen Prozess startet.

[darktrym]

Über eine Pipe an die Shell müsste es doch gehen, noch keine Ahnung wie das aussehen muss.

[Sirius3]

@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.

[jerch]

@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.

[darktrym]

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.

[jerch]

@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.

[darktrym]

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?