Am Freitag, 11. Februar 2005 23:23 schrieb Bernd Brodeßer:
Am Freitag, 11. Februar 2005 22:08 schrieb Thomas Janssen:
Am Freitag, 11. Februar 2005 21:49 schrieb Bernd Brodeßer:
Am Freitag, 11. Februar 2005 18:51 schrieb Thomas Janssen:
Mein Problem ist jetzt, wenn ich es nun kontrolliert beenden möchte (nicht per kill),
Was spricht gegen kill?
Ist ein Quit in einem Programm und ein Kill das selbe ? Ich denke nicht. Mit dem Quit werden zuerst noch alle offenen Dinge(tm) beendet und gespeichert. Mit kill auch ?
Was ist Quit? Das Programm kenne ich nicht.
Die Funktion "Quit" - "Beenden" eines Programmes. Ich denke das kennst Du sehr wohl. Da ich kein Programmierer bin, kann ich nicht sagen ob das ein kill auslöst.
könnte ich das nur in einer Konsole. Doch da taucht das Teil nicht auf. Jobs bringt keine Ausgabe. Gibt es eine Möglichkeit zum Beispiel an Hand der PID (die kriege ich per Top) die Ausgabe des Programmes irgendwie in (m)eine Konsole zu bekommen. Oder sollte ich mein Script abändern das ich die Ausgabe des Programmes (und dadurch den Zugriff) in der Konsole haben kann.
Wie kommst Du auf die merkwürdige Idee, daß Du mit der Ausgabe auch einen Zugriff auf das Programm hast? Wenn schon, dann durch die Eingabe, was was völlig anders ist. Aber die Frage bleibt, was Du unter Zugriff meinst.
Was für einen Zugriff hast Du auf Mutt ?
Du meinst Standardeingabe, Standardausgabe und Standardfehlerausgabe? Wenn man es nicht umlenkt, dann auf der Konsole von der man es aus startet. Ganz normales verhalten.
Das meine ich, das normale Verhalten.
Es ist ein Konsolenprogramm, das bedeutet ich kann damit in der Konsole arbeiten.
Jedes Programm ist dann ein Konsolenprogramm, denn jeder Prozeß hat eine Standardeingabe, eine Standardausgabe und eine Standardfehlerausgabe. Es kann natürlich sein, daß das Programm ein Teil davon oder alles nicht nutzt.
Ok, Du willst mich nicht verstehen, sondern mir etwas über stdin, stdout und stderr beibringen. Ich möchte aber kein Script basteln das über 40 Zeilen geht und alles mögliche umlenken muss.
Vorraussetzung ist allerdings das es auch in der Konsole läuft. Wenn ich es aber mit meinem Watchdog starte habe ich keinen Zugriff darauf, kann nicht damit arbeiten.
Ja, dann muß Du Standardeingabe, Standardausgabe und Standardfehlerausgabe umlenken, da dem Prozeß keinen Bildschirm zugeordnet wird
Kann ihm keine Befehle übermitteln und sehe nicht was abläuft. Kein Zugriff. Ausser kill.
Habe ich geschrieben, Du muß Standardausgabe, -eingabe und auch -fehlerausgabe auf einen Bildschirm umlenken. Bei Unix/Linux verhält sich ein Bildschirm nicht anders als eine Datei. Mit programm > datei schreibst Du die Ausgabe in die Datei datei und mit programm > /dev/tty4 schreibst Du die Ausgabe auf die virtuelle Konsole 4
Das ganze muss ich doch nicht extra umlenken, wenn das Programm sofort in einer Konsole startet. konsole -e "/usr/bin/edonkeyclc" -g würde das ja eigentlich machen. Nur kommt da eine aufpoppende Konsole die sich nach 1 Sekunde mit Signal 1 wieder verabschiedet. Also denke ich mir das die letzte Option -g daran schuld ist, da die Konsole sich vermutlich mit der Option angesprochen fühlt. Oder dann die andere Frage, warum verabschiedet sich die Konsole nach 1 Sekunde wieder mit Signal 1 ?
Ganz davon ab ist das ganze soweit ja gelöst, bis auf das Quoting (wenn man es denn so nennt). Es läuft jetzt in einer Konsole nur fehlt noch die "Programmoption -g" die ich nicht gebacken bekomme. Siehe die Beispiele in meinem anderen Posting.
Mich interessiert hier nicht so sehr darum, daß Dein konkretes Problem gelöst wird, sondern mehr darum, daß Du und andere Mitleser verstehen, wie Linux und besonders die Prozesse darin funktionieren. Wenn Du da Ahnung von bekommst, dann bringt Dich das wesentlich weiter im Verständnis von Linux, als wenn nur irgend ein Programm läuft und Du weißt nicht warum.
Vielen Dank Bernd das Du versucht hast das Problem zu verstehen. Gruss Thomas