imhotep schrieb:
Da popen() zu stdio.h gehört, könntest du einfach im Verzeichnis /usr/include nach stdio.h schaun und die dir mal ansehen.
extern FILE *popen (__const char *__command, __const char *__modes);
In Headern steht doch kein Source Code drin!
LEO 3 schrieb:
1. Der Source lauft auf dem Z/OS ( OS/390) Mainframe ...
2. Der Source läuft reentrend (RENT) das bedeutet das das Programm mehrmals gleichzeitig läuft. Aus diesem Grund muss ich es auch schaffen das der beim Lock wartet.
_reentrant_. ich weiss was das ist.
was heisst mehrmals ? mehrere threads oder mehrere prozesse ?
LEO 3 schrieb:
Ist ja cool wenn der nicht wartet nur wie krig ich den zum warten ohne das ich den loop durchlaufe. ( ich steh nicht so auf loops ) da muss es doch eine ander Lösung geben ....
tja, vielleicht besseres design ? oder mal überlegen ob du nicht doch
rekursives locken zulassen kannst.
Martin G schrieb:
Eine Beschreibung und Beispielprogramme zu den ioctl()-Aufrufen [...]findest du einsteigergerecht in meinem Buch "C und Linux".
OMG Du bist der Martin Gräfe??
Welch ein Zufall. Genau Dieses Buch hab ich hier vor mir liegen (aus der Bibliothek). Aus diesem Grund bin ich überhaubt auf diese Frage gekommen.
Gefällt mir Gut das Buch, kann die Fortsetzung nicht erwarten
gruss
Es gibt zwei Möglichkeiten festzustellen, ob Du alle Daten bekommen hast. Entweder der Client schließt am Ende die Verbindung, dann wird serverseitig ein eof erkannt, oder der Datenstrom ist so gestaltet, daß ein Ende erkannt wird. Anders geht es nicht.
Bei HTTP gibt es mehrere Varianten. Der Request wird mit einer Leerzeile beendet. Daran erkennt der Server, daß der Client alles geschickt hat. Bei einem POST-request muß der Client aber noch weitere Daten schicken. Dafür muß er im Header allerdings eine Zeile "Content-Length: xxx" angeben, damit der Server weiß, wie viele Bytes er zu empfangen hat.
Der Server kann es sich beim Reply einfacher machen. Er schickt die Antwort und macht ein close. Er benötigt die Verbindung zum Client ja nicht mehr. Das ist die klassische Variante. Das hat sich als nicht sehr performant erwiesen, da für jeden Request eine neue Verbindung aufgebaut werden muß. Daher hat man später im HTTP eine andere Variante namens Keep-Alive definiert.
Wenn der Client über einen bestimmten HTTP-Header signalisiert, daß er keep-alive kann, darf der Server auch keep-alive machen. Dazu muß er wieder im Header ein Content-Length angeben. Dann weiß der Client wieder, wann er mit dem read fertig ist und kann den Socket für den nächsten Request verwenden.
Übrigens, wenn Du C++ programmierst (wir sind hier ja auf www.c-plusplus.net), kannst Du eine der Zahlreichen Bibliotheken verwenden, wie z. B. socket++ oder meine cxxtools (unter www.tntnet.org zu finden).
Für HTTP nimmt man natürlich tntnet
Gruß
Tommi
Danke! Ich hab dazu was gefunden was mich weiter gebracht hat und das funktioniert auch. Ich verwende jetzt allerdings XTestFakeKeyEvent(). Jetzt ergibt sich für mich eine weitere Frage: Wie kann ich KeyEvents lesen, wenn das Fenster meiner Anwendung nicht den Fokus hat?
Gruß,
miho
Dass das C++ Code sein sollte war mir klar. Nur ohne das jemand die Klasse die du verwendest kennt, kann man dir ja schlecht helfen
sfds
Aber wenn es jetzt funktioniert ist es ja gut.
Sorry, ich möchte nicht, dass das hier ausartet.
Wenn Du Dir nicht die zusätzlichen Pakete herunterladen möchtest, dann bestell Dir einfach irgendwo gratis Ubuntu oder so.
Du willst wirklich telnet auf einem Debian-Sarge-Rootserver im Internet verwenden? Das wundert mich. Gibt es den Telnet-Server unter Debian-Sarge überhaupt noch? Wenn ja, dann solltest Du ihn deinstallieren. In solchen Fällen nutzt man heutzutage ssh. Damit ist die automatische Anmeldung und Umleitung der Ausgaben auch wesentlich einfacher.
Du mußt auf deinem lokalen Rechner einen ssh-Schlüssel erzeugen und auf dem Debian-Server unter $HOME/.ssh/authorized_keys hinterlegen. Damit klappt die automatische Anmeldung und auch die Ausgabeumleitung. Mit
ssh rechnername ls -l >textdatei.txt
bekommst Du die Ausgabe in eine lokale Datei.
Details findest Du mit "man ssh".
Das mit den Prozessen ist vollkommen Compilerunabhängig.
Was Unterprozess von was ist, kommt ganz darauf an, was von wem gestartet wird.
Z.B. ist init der erste Prozess. Alles andere sind Unterprozesse.
Unter KDE gibt es bestimmt auch ein Programm welches die Prozesse startet die du haben möchtest.
Startest du ein Xterm und darin ein Programm, dann ist das Xterm Unterprozess von KDE.
init
|- KDE
| |-Konqueror
| \-xterm
| \-wget
\-bash
Das Programm wget würde weiterlaufen wenn du es ihm richtig sagst:
igor@pc $ nohup wget ??? &
Damit geht das Programm erst mal in den Hintergrund (&) und wird nicht beendent wenn du die Shell schließt (nohup).
Eventuell solltest du dir noch die Prozessid geben, damit du nachher noch auf den Prozess zu greifen kannst.
Es macht ja auch keinen Sinn, das Passwort in einer Funktion GetPWD() zu verstecken und dort wirr mit ein paar char* rumzuhantieren.
Am Ende der Funktion wird eh das Passwort zurückgegeben und steht damit in einem Register das ausgelesen werden kann..
warum ist das ne schlechte idee?
man kann das jetzt noch um einen schutz erweitern der das skript abbricht wenn der prozess zu schnell beendet wird ...
habs nun so probiert:
my ssh=Net::SSH::Perl−>new(ssh = Net::SSH::Perl->new(ssh=Net::SSH::Perl−>new(host, port => 3314);
->
Can't connect to rftplinux.homelinux.org, port 3314: Connection refused at /usr/lib/perl5/vendor_perl/5.8.6/Net/SSH/Perl.pm line 206.
cplusplus rftplinux.homelinux.org v
mit commandline klappts...
ssh xxxxx 3314
cu
Hallo.
Ich bedanke mich für die Antworten und Lösungsvorschläge.
Ich denke, in diesem Fall, wird es wohl das sinnvollste die Funktion fopen64 zu verwenden, ist ja genau für diesen Zweck vorgesehen.