Anmelden

Archiv verlassen und diese Seite im Standarddesign anzeigen : Perl: exec mit Array,



Thomas Engelke
05-06-2003, 07:15
Hallo!

Ich versuche, eine Entwicklungsumgebung aus einem Win32-Perl-Script heraus zu starten. Dazu benötige ich eine Möglichkeit, auf der Shell diverse Statements abzusetzen und dann das Script (inklusive des dazugehörigen DOS-Fensters) zu schließen.

Dazu wollte ich zuerst innerhalb eines Loops das jeweilige Statement mit

system("statement")

ausführen und das Script beenden. Ich bemerkte, system würde auf das Ende des Childprozesses warten. Also perldoc -> exec gefunden. Dann bin ich dazu übergegangen, wie in perlfunc angegeben (exec LIST) ein Array mit den Kommandozeilen zu bauen.

my @runme;
while ($instanzen) {
push @runme, "c:\\dlc91d\\bin\\prowin32.exe -ininame D:\\dev\\prg\\91d.ini -pf D:\\dev\\prg\\91d.pf -p D:\\dev\\prg\\pp_perl.p";
$instanzen--;
};

Dieses will ich dann per

exec(@runme) or die "Cannot run statements ...\n";

ausführen. Dies ergibt einen Fehler, sobald das Array mehr als einen Eintrag beinhaltet. Es scheint nicht an der Art der Einträge zu liegen, 2 "CLS" erzeugen genau denselben Fehler:

<Fehlermeldung>
c:\dlc91d\bin\prowin32.exe -ininame D:\dev\prg\91d.ini -pf D:\dev\prg\91d.pf -p D:\dev\prg\pp_perl.pc:\dlc91d\bin\prowin32.exe -ininame D:\dev\prg\91d.ini -pf D:\dev\prg\91d.pf -p D:\dev\prg\pp_perl.pCan't exec c:\dlc91d\bin\prowin32.exe -ininame D:\dev\prg\91d.ini -pf D:\dev\prg\91d.pf -p D:\dev\prg\pp_perl.p": Invalid argument at path.pl line 145, <STDIN> chunk 4.
Cannot run statements ...
</Fehlermeldung>

Es scheint mir, als habe ich den Abschnitt exec in perlfunc nicht richtig interpretiert bzw. verstanden. Kann mir da jemand helfen?

Vielen Dank!

AD!

spike
05-06-2003, 07:37
ich verwende Perl zwar ausschliesslich auf Unix, aber bei der exec funktion ist mit LIST meiner Meinung nach nicht eine Befehlskette gemeint sondern der Aufruf eines Programms mit Parametern.

Wenn man eine Liste statt eines Strings übergibt sollte das eine eine Shell sparen:


exec("ls -l DIR1 DIR2"); --> Perl muss zusätzliche subshell aufmachen um den Befehl zu interpretieren
exec("ls", "-l", @DIRS); --> Perl kann direkt Kommando an die Shell weitergeben


Die Fehlermeldung wird bei Dir dann wohl von dem ersten Programm das Du aufrufst ausgelöst der die Argumente nicht verarbeiten kann.

Ich muss zugeben das ich die Lösung System Call by System Call auch sauberer finde und würde deshalb auch dazu zurückkehren.

Grüße, Spike

Thomas Engelke
05-06-2003, 08:07
Interessanter Ansatz. Danke für die Idee. Dies hat zumindest das Mysterium des exec LISTE gelöst. Spannenderweise führen mehrere exec nur zur Ausführung eines dieser Statements (es sind dieselben, deshalb ist es für mich schrierig, zu erkennen, welches ausgeführt wird). Ich werd's in jedem Falle erstmal noch weiter verfolgen. Danke.

AD!

Edit: Scheinbar habe ich das Problem verkannt. Ich möchte ja eigentlich mehrere Instanzen derselben Applikation starten, jedoch nicht auf deren Rückkehr warten. exec jedoch bricht alles nach der ersten Ausführung ab. Da ich aber zur Compiletime nicht weiss, um wieviele Instanzen es sich handelt, kann ich nicht auf exec LISTE (speziell LISTE) zurückgreifen, diese muß ja dafür statisch sein. Eine Idee?

sticky bit
06-06-2003, 03:14
Naja, exec() ersetzt den PERL Prozess ja Quasi mit dem Versuch das Programm zu starten was in den Argumenten ist. Und zwar das erste, weil das zweite kann es nicht mehr starten, der PERL Prozess lebt ja nicht mehr. (Oh, Gott, was für ein komischer Satz...)

Wenn ich dein Problem richtig verstanden habe wirst du dich wohl mit Threading auseinanderstezen müssen...

Thomas Engelke
06-06-2003, 12:21
Ich hatte schon an diese Idee gedacht, aber war mir eigentlich ziemlich sicher, dass ein exec innerhalb eines geforkten Childs trotzdem den Perl-Interpreter killt. Ich schau aber da nochmal nach. Danke!

AD!

Edit: Schwierig zu testen, ein "fork" unter Win32 bringt "The Unsupported function fork function is unimplemented at path.pl line 138, <STDIN> chunk 4.". Schade, das hätte die Lösung sein können.