C++ interaktives command read AND write

hi,

Ich möchte einen interaktiven command in einem C++ Programm starten. Das wichtige ist, dass ich neben dem reading was ja mit popen eig kein Problem darstellt auch etwas hinausschicke möchte.

Also Beispiel kann sich vllt folgendes vorstellen:
In C++ wird der Befehl Python hinausgeschickt und gelesen(mit popen z.B.), gleichzeitig möchte ich aber befehle hinausschicken, die dann in diesem Beispiel die aufgerufene Python konsole empfängt.

Mal ganz unabhängig vom Thema threading würde ich nur gerne wissen wie ich das prinzipiell umsetzen kann.

Danke

edit:
also quasi ein comand der neben dem einlesen auch etwas vom benutzer erwartet.
 
Zuletzt bearbeitet:
Ähm eig nein...
sowie ich das verstanden habe ging es in dem Beispiel das du mir geschickt hast, darum einen comandB an einen anderen comandA zu schicken.

Mein Ziel ist es aber das ComandB and ComandA zu schicken und das Ergebniss von comand A zu lesen. Ich bräuchte im Prinzip eine pipe mit popen die "w" und "r" ist, also in die ich schreiben und lesen kann und das abwechselnd von zwei verschieden Threads.

So etwas wie bei einem Chat im Terminal. Dabei möchte ich dann im einen Thread aus der Pipe lesen(was z.B. andere geschrieben haben) und im anderen Thread in die pipe schreiben(was der benutzer zurück schreiben will).

Ich hoffe jetzt ist es etwas verständlicher
 
So etwas wie bei einem Chat im Terminal. Dabei möchte ich dann im einen Thread aus der Pipe lesen(was z.B. andere geschrieben haben) und im anderen Thread in die pipe schreiben(was der benutzer zurück schreiben will).

Ist vielleicht Pipe-Multiplexing etwas fuer Dich?

Ansonsten finde ich deine Beschreibung etwas zu ungenau, bseonders wenns um sowas wie IPC geht.
 
Unter unixoiden (?) Betriebssystemen solltest du select nutzen können.
Damit kannst du dann den gleichzeitig Nachrichten von dem per popen geöffneten Proccess empfangen und ausserdem Input von STDIN.
Hier mehr The World of select() (nur überflogen)

Keine Ahnung wie das unter Windows ausschaut.
 
Ich versuche es noch etwas näher zu beschreiben:

Ich habe einen Chat der per Console zu bedienen ist. Diesen möchte ich gerne in ein GUI übertragen. Dazu möchte ich eine Pipe vom Chat öffnen, also einfach der bash Befehl und aus dieser einerseits lesen was von anderen geschrieben wurde und andererseits schreiben, was der Benutzer in den GUI eingibt.

Also Ein und Ausgabe von ein und demselben aufgerufenen Comand in einer Console
 
Dann guck die Dokus zur BASH und Pipes (auch background pipes) in der BASH an - das ist schnell erklärt. Allerdings, wenn du auf der BASH Ebene pipen willst, fürchte ich, wirst du nicht weit kommen, da diese pipes zu einseitigen Streamumleitung gedacht sind (anonyme pipes, ein prozess schreibt, einer liest, also eine one-way pipe).

Die (so vermute ich noch immer) von dir gesuchten pipes waeren "named pipes", wie man sie in c/c++ benutzen kann um 2 Prozesse miteinander kommunzieren zu lassen (IPC). Oder wie Sleepprogger meinte, schaust dir mal SELECT an.

Allerdings würde ich bei dem Design eines solchen Chats eher auf sockets setzen.
 
soweit ich ihn verstehe will er aus seinem programm einen neuen prozess öffnen und stdin / stdout dieses prozesses beschreiben / lesen

unter windows willst du dafür die STARTUPINFO Struktur entsprechend vor dem prozess start befüllen, im speziellen das dwFlag STARTF_USESTDHANDLES sowie die 3 handles für stdin stdout und stderr

unter linux wird das vermutlich ähnlich funktionieren ... ich vermute mal du musst dir die ersten drei file descriptors des neuen prozesses krallen, oder beim prozessstart festlegen mit welchen pipes die arbeiten sollen

im zweifel wirst du vermutlich auf /proc/<pid>/fd/0 schreiben können, und dem programm beim starten ein FIFO als ausgabe mitgeben können, welches du dann von deinem prog aus lesen kannst

mit sicherheit kann ich dir das aber nicht sagen, da ich aktuell eher in der windosen welt arbeite
 
unter linux wird das vermutlich ähnlich funktionieren ... ich vermute mal du musst dir die ersten drei file descriptors des neuen prozesses krallen, oder beim prozessstart festlegen mit welchen pipes die arbeiten sollen

Oder er könnte es einfach ganz old-school mässig "forken" und den GUI Prozess dann in nem child starten und dann dort ueber named pipes (oder sockets) kommunizieren.
 
Oder er könnte es einfach ganz old-school mässig "forken" und den GUI Prozess dann in nem child starten und dann dort ueber named pipes (oder sockets) kommunizieren.
soweit ich ihn verstehe existiert das client programm schon, und er will nur eine gui drauf pflanzen die die consolen-anwendung in die klickie buntie welt hebt ...
 
Zurück
Oben