PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Programm aufrufen - wie Output lesen?


Gast
2008-07-22, 16:12:44
Hi,

ich möchte in meinem Programm ein anderes aufrufen. Mit fork, exec usw sollte das gehen, aber wie bekomme ich den Output des Kindprogramms (Kommandozeilenprogramm)? Z.b. zum anzeigen?

lg

MadMan2k
2008-07-22, 16:24:46
ganz einfach:

import commands
commands.getoutput("ls")

The_Invisible
2008-07-22, 16:25:10
welche programmiersprache / os?

ansonsten such einfach mal nach popen.

mfg

Monger
2008-07-22, 16:28:13
Uäähh. Muss das sein?

Programme sind - konzeptionell mal gesehen - voneinander unabhängig. Windows gibt sich ja extra Mühe, schon aus Sicherheitsgründen die einzelnen Prozesse voneinander möglichst gut zu isolieren.

Es geht schon irgendwie, aber EIGENTLICH macht man zu solchen Zwecken einen neuen Thread auf. Die sind leichtgewichtig, und nunmal dazu gedacht sich gegenseitig mit Informationen zu versorgen.

Ist es also wirklich notwendig, dass du hier einen neuen Prozess eröffnest?

Gast
2008-07-22, 16:35:43
Uäähh. Muss das sein?

Programme sind - konzeptionell mal gesehen - voneinander unabhängig. Windows gibt sich ja extra Mühe, schon aus Sicherheitsgründen die einzelnen Prozesse voneinander möglichst gut zu isolieren.

Es geht schon irgendwie, aber EIGENTLICH macht man zu solchen Zwecken einen neuen Thread auf. Die sind leichtgewichtig, und nunmal dazu gedacht sich gegenseitig mit Informationen zu versorgen.

Ist es also wirklich notwendig, dass du hier einen neuen Prozess eröffnest?
Nein, nicht unbedingt. Ich will nur aus einem Programm heraus ein anderes aufrufen und steuern. Ob ich dazu einene neuen Prozess oder nur einen Thread mach ist eigentlich egal, nur fork+exec kenn ich halt schon.


welche programmiersprache / os?

C++ / Linux

lg

Pinoccio
2008-07-22, 16:40:38
Ich werde aus deinem Problem zwar nicht ganz schlau, aber möglicherweise könnet expect auch eine hilfreiches Stichwort sein.
http://expect.nist.gov/
http://deaddodo.org/mikiwiki/index.php/expect
http://www.clug.in-chemnitz.de/vortraege/expect/expect.html
http://users.csc.calpoly.edu/~dbutler/tutorials/winter96/expect/tutorial.html

/edit: okay, dann hilft dir das nicht. ;-)

mfg

Gast
2008-07-22, 16:55:31
Ich werde aus deinem Problem zwar nicht ganz schlau, aber möglicherweise könnet expect auch eine hilfreiches Stichwort sein.
http://expect.nist.gov/
http://deaddodo.org/mikiwiki/index.php/expect
http://www.clug.in-chemnitz.de/vortraege/expect/expect.html
http://users.csc.calpoly.edu/~dbutler/tutorials/winter96/expect/tutorial.html

mfg
Sorry, "steuern" war vielleicht nicht der richtige Begriff. Ich möchte es einfach ein Programm "aufrufen" (mit Argumenten) und den Output den es produziert in irgeneiner Weise zur Verfügung haben.

lg

Gast
2008-07-22, 17:11:51
Kenn mich mit Unix nicht aus, aber vlt hilft dir das: http://bytes.com/forum/thread532067.html

Ectoplasma
2008-07-23, 13:34:37
Da steht genau, was du möchtest.

http://www.gmonline.demon.co.uk/cscene/CS4/CS4-06.html

Unter Windows geht das im Prinzip auch. Windows kennt nur kein fork.

@Monger

Das ist nicht Uäähh, sondern oft im Gegenteil, sehr sehr brauchbar.
Das ganze Consolen-Piping läuft so. Unter Unix Systemen ist das sogar der Klassiker. Unter Windows funktionierts genau so.

Shink
2008-07-23, 13:40:17
Das ist nicht Uäähh, sondern oft im Gegenteil, sehr sehr brauchbar.
Ich frag mich gerade was genau Monger damit meint.

Ist nunmal das Unix-Prinzip: Ein Programm ist genau für einen Zweck. Wenn man etwas komplizierteres erreichen will müssen sich somit mehrere Programme gegenseitig aufrufen.

Monger
2008-07-23, 13:48:41
Ist nunmal das Unix-Prinzip: Ein Programm ist genau für einen Zweck. Wenn man etwas komplizierteres erreichen will müssen sich somit mehrere Programme gegenseitig aufrufen.

Wenn ein Programm auf die Verarbeitung eines anderen Programms angewiesen ist, ist es eben eigentlich kein eigenständiges Programm! ;)

Ein eigenständiger Prozess ist halt etwas ziemlich schwergewichtiges. Sich irgendwie über den Kommandozeilenoutput langzuhangeln, ist nicht nur inperformant und frickelig, sondern auch noch ziemlich instabil: da müssen sich nur mal die Rechte für ein bestimmtes Installationsverzeichnis ändern, und plötzlich bricht die ganze Kette zusammen.

Ich sag ja nicht dass es nicht geht - ich sag nur, dass man zumindest mal über etwas leichtgewichtigeres wie eben Threads nachdenken sollte! ;)
Da spart man sich möglicherweise viel Ärger.

pest
2008-07-23, 14:37:31
bei Kommandozeilenprogrammen, mach ich das mit Pipes.

Pinoccio
2008-07-23, 14:45:58
Wenn ein Programm auf die Verarbeitung eines anderen Programms angewiesen ist, ist es eben eigentlich kein eigenständiges Programm! ;)*ix verfolgt da einen völlig anderen Ansatz. Viele Kleine schaffen eine großes Ganzes.
Zum Beispiel GMT (http://gmt.soest.hawaii.edu/), eine Sammlung aus rund 60 Tools, deren Kombination [i]die[/] Software zum Kartenerstellen schafft.

mfg

(Möglicherweise ist auch mein Ironiedetektor noch nicht ganz wach.)

Monger
2008-07-23, 15:09:57
*ix verfolgt da einen völlig anderen Ansatz. Viele Kleine schaffen eine großes Ganzes.

Noch einmal: Wenn alle Programme abgegrenzt voneinander arbeiten können, ist das ja auch völlig vernünftig.

Können sie das nicht, kann es Probleme geben. Das Betriebssystem ist eigentlich nicht darauf ausgerichtet, Kommunikation zwischen Prozessen im großen Stil umzusetzen. Dafür hat es zu wenig Informationen, um mit den Prozessen sinnvoll umzugehen. Was passiert, wenn der Speicher knapp wird? Welches soll ausgelagert werden? Welches soll abgeschossen werden, wenn Probleme auftauchen? Was passiert wenn sich Abhängigkeiten ändern, wenn z.B. einer der Prozesse gepatcht wird? Sollen die anderen Prozesse dies nun als Sicherheitsrisiko verstehen, oder einfach weitermachen?

Zumindest in der Windows Welt sind selbst die Dienst meistens allenfalls vier Ebenen tief gestapelt, damit ist aber schon das Maximum an Komplexität bei den Abhängigkeiten erreicht.

Ectoplasma
2008-07-23, 16:47:48
Noch einmal: Wenn alle Programme abgegrenzt voneinander arbeiten können, ist das ja auch völlig vernünftig.

Können sie das nicht, kann es Probleme geben. Das Betriebssystem ist eigentlich nicht darauf ausgerichtet, Kommunikation zwischen Prozessen im großen Stil umzusetzen. Dafür hat es zu wenig Informationen, um mit den Prozessen sinnvoll umzugehen. Was passiert, wenn der Speicher knapp wird? Welches soll ausgelagert werden? Welches soll abgeschossen werden, wenn Probleme auftauchen? Was passiert wenn sich Abhängigkeiten ändern, wenn z.B. einer der Prozesse gepatcht wird? Sollen die anderen Prozesse dies nun als Sicherheitsrisiko verstehen, oder einfach weitermachen?

Zumindest in der Windows Welt sind selbst die Dienst meistens allenfalls vier Ebenen tief gestapelt, damit ist aber schon das Maximum an Komplexität bei den Abhängigkeiten erreicht.

Also was du jetzt als Gegenargumente schreibst, ist aber nun mal schon seit Jahrzenten praxiserbrobt und läuft bestens. Natürlich sind deine Gegenargumente auch richtig, aber die Vorteile, dass Prozesse sich gegenseitig aufrufen, sind auch nicht zu verachten. Schmiert z.B. ein Prozess ab, schmiert deshalb nicht das ganze Prozessnetzwerk ab. Prozesse kann man mal eben im Betrieb austauschen. Sie sind viel Handlicher. Das ganze Deployment ist dadurch einfacher etc. Die Kommunikation über Pipes ist einfach und schnell herzustellen. Mit Threads und DLLs könnte man das auch machen. Der Aufwand dafür ist aber ungleich größer. Siehe z.B. C/C++ Compiler. Fast keine einzige C/C++ IDE würde auf dei Idee kommen, den Compiliervorgang intern abzufeuern. Stattdessen wird der Kommandozeilen-Compiler aufgerufen und dessen Ausgabe in ein Fenster gepiped.

Es ist eben auch eine Frage der Anforderung an ein System, welche Lösung man bevorzugt. Die Kommunkation über Prozesse hat aber in jedem Fall seine Daseinsberechtigung.

Shink
2008-07-23, 16:56:59
Noch einmal: Wenn alle Programme abgegrenzt voneinander arbeiten können, ist das ja auch völlig vernünftig.

Können sie das nicht, kann es Probleme geben. Das Betriebssystem ist eigentlich nicht darauf ausgerichtet, Kommunikation zwischen Prozessen im großen Stil umzusetzen.
Also irgendwie kann ich nicht ganz glauben dass du das ernst meinst. Vielleicht schätze ich die Moderation hier aber auch falsch ein.

Monger
2008-07-23, 17:22:43
Schmiert z.B. ein Prozess ab, schmiert deshalb nicht das ganze Prozessnetzwerk ab.

Das gilt für Threads genauso. Im Gegensatz zum Betriebssystem ist man aber nicht nur auf ein paar festgelegte Return Codes festgelegt, sondern kann sehr differenziert reagieren.

Prozesse kann man mal eben im Betrieb austauschen.

Ohne die Verarbeitungskette abzuschalten? Das kann in die Hose gehen!

Bei Threads ist es nicht unüblich, mal schnell ein paar hundert zu erzeugen und wieder zu konsumieren. Mach das mal auf Prozessebene! ;)


Es ist eben auch eine Frage der Anforderung an ein System, welche Lösung man bevorzugt. Die Kommunkation über Prozesse hat aber in jedem Fall seine Daseinsberechtigung.
Ja, natürlich. Und du hast schon Recht, dass die Handhabung mit Threads auch ziemlich qualvoll sein kann. Aber meiner Einschätzung nach werden halt Prozesse immer noch gnadenlos über- und Threads deutlich unterbewertet! ;)

Also irgendwie kann ich nicht ganz glauben dass du das ernst meinst. Vielleicht schätze ich die Moderation hier aber auch falsch ein.
Nana, jetzt mal nicht auf dem Moderationstitel rumreiten! Ich hab auch ein Recht darauf, gewagte Thesen mit vollkommener Ernsthaftigkeit aufzustellen! ;)

Gast
2008-07-23, 17:28:09
Danke für die Antworten, sieht sehr vielversprechend aus.

@Monger: Wie würde denn das ganze mit Threads funktionieren? Also welche Befehle brauch ich da?

Ectoplasma
2008-07-23, 17:42:44
Das gilt für Threads genauso.

Ich will jetzt keine große Diskussion losbrechen, aber in dem Punkt irrst du sehr. Die Abgrenzung zum Speicher des Hauptprozesses ist nicht gegeben. Ein Thread kann sonstwas angerichtet haben. Wenn der abschmiert kann man das zumindest in C++ über eine "ekeliges" try {} catch (...) {} abfangen, aber du hast keine Sicherheit, dass der Prozess noch vernünftig läuft.

Ich bin nicht gegen Threads, ganz im Gegenteil. Ich habe im Internet und in Photografie-Foren eine HDRI - Software in der Entwicklung (Picturenaut), die je nach Anwendungsfall, mal mit Threads und mal mit dem Aufruf von Prozessen arbeitet.

@Gast, fragst du wirklich nur Monger? Dürfen wir auch antworten? :D

Monger
2008-07-23, 17:59:54
@Monger: Wie würde denn das ganze mit Threads funktionieren? Also welche Befehle brauch ich da?

Im einfachsten Falle kenne ich das so, dass man eine Thread Klasse hat von der man erben muss, und dann das was in dem Thread laufen soll in die Run Methode packt. Dann instanziiert man den Thread, ruft "start()" darauf auf, und der läuft dann eben irgendwo asynchron vor sich hin. Wenn du auf das Ergebnis des Threads warten willst, rufst du "Join()" auf... dann stoppt dein Programm so lange bis die "Run" Methode des Threads durchlaufen ist. Dann wertest du den Thread aus (z.B. indem du irgendeine Variable ausliest die er dort gesetzt hat), und machst mit diesem Ergebnis weiter.

Threads sind ein großes Thema, darüber kann dir dann Ectoplasma gerne mehr erzählen! :D

Gast
2008-07-23, 21:17:47
Im einfachsten Falle kenne ich das so, dass man eine Thread Klasse hat von der man erben muss, und dann das was in dem Thread laufen soll in die Run Methode packt. Dann instanziiert man den Thread, ruft "start()" darauf auf, und der läuft dann eben irgendwo asynchron vor sich hin. Wenn du auf das Ergebnis des Threads warten willst, rufst du "Join()" auf... dann stoppt dein Programm so lange bis die "Run" Methode des Threads durchlaufen ist. Dann wertest du den Thread aus (z.B. indem du irgendeine Variable ausliest die er dort gesetzt hat), und machst mit diesem Ergebnis weiter.

Threads sind ein großes Thema, darüber kann dir dann Ectoplasma gerne mehr erzählen! :D
Achso, das kenn ich ja... :)
Bleibt das grundsätzliche Problem dass ich dann in der Run() Methode irgendwie mein Kommandozeilenprogramm aufrufen muss, insofern bringt mich das nicht wirklich weiter...