ubuntuusers.de

Ich möchte aus einem Script heraus das Signal ctrl-d senden. Das habe ich versucht via echo -e "X", wobei X das Steuerzeichen ist. Mit \n, \r, \t klappt das hervorragend - liegt also wohl am Steuerzeichen, das ich nicht kenne. \x4, \x004, \4, \004 scheinen keine Ausgabe zu bewirken. Scheint trivial zu sein - aber ich finde die Lösung weder vai google noch durch probieren :/

df8oe

Strg+d ist ein Signal und kein Steuerzeichen. Signale sendet man mit 'kill'.

Dann muß ich meine Frage konkretisieren. Habe deine Antwort zwar verstanden, eine Lösung kann ich mir daraus aber nicht basteln...

Ich bin in einer Konsole, die, wenn ich control-d drücke, geschlossen wird und es werden weitere, vorgegebene Aktionen ausgeführt.

In dieser Konsole nun starte ich ein Bashscript, es können via dialog diverse Einstellungen vorgenommen werden und Aktionen werden ausgeführt. Wenn der User das Script beendet, soll das Script "ctrl-d senden", damit das gleiche passiert, was passiert wäre, als wenn auf der Konsole selbst ctrl-d gedrückt worden wäre.

- welches Signal ist "ctrl-d" ? - an welchen Prozess muß das Signal gesendet werden? Muß ich die Prozess-ID der Konsole ermitteln und das Signal an diese senden?

Für einen weiteren Tipp wäre ich dankbar...

df8oe

Ctrl-D schreibt EOT, was unter Unix für "Datei-Ende" benutzt wird. Wenn die Shell EOT liest, beendet sie sich, und damit dann auch das Terminal-Programm.

Mit echo kommst du da nicht weiter, weil du nach stdin der aufrufenden Shell schreiben müsstest statt nach stdout des Skripts.

Eine Möglichkeit wäre, deinen Code als Shell-Funktion statt als Skript zu schrieben. Dann kannst du die Shell einfach mit exit beenden. IN einem Sktript müsstest du die PID des Eltern-Prozesses killen (und idealerweise vorher prüfen, ob das auch wirklich eine Shell ist)

Also erstmal: Ich glaube ich habe mich vertan. control+d sendet das EOT-Zeichen und ich denke, dass ist dann natürlich kein Signal.

Aber ich glaube dein Ansatz ist schon falsch. Zum einen bedeutet EOT ja nicht „Terminal schließen”, sondern nur, dass die Eingabe beendet ist. Was das konkret bedeutet, hängt vom dem Prozess ab, der die Eingabe ließt. Bsp:

cat
^d

beendet hier nur cat und nicht das Terminal.

Daneben finde ich deine Lösung, Aktionen vom Beenden des Terminals abhängig zu machen sehr ungewöhnlich und ich denke, dass das ein Design-Fehler ist.

Wie auch immer: Das Terminal wird durch ^d beendet, weil die Interaktive-Shell die gerade läuft beendet wird, da sie keine Eingabe mehr hat. Wenn du ein Terminal schließen willst, nachdem ein Script beendet ist, dann kannst du dazu „exec” benutzen. „exect <dein Script>” ersetzt den Shell-Prozess durch das Script und sobald das Script beendet ist, ist auch der Sub-Prozess des Terminals beendet und es sollte sich schließen.

Servus,

^D ist kein Signal, sondern bedeutet „flush(current_fd)“. Ist hier bei Stack Overflow schön erklärt. Oder, was man auch mal erwähnen kann: Im schönen Klassiker The Unix Programming Environment auf Seite 45. 😉 „kill“ hilft dir jedenfalls nicht weiter.

Aber ich lese dein Problem so, dass du eigentlich gar nicht in die Problematik rennen solltest, wenn du es etwas anders aufziehst. Entweder, du startest das Terminal und gibst ihm direkt zu verstehen: „Starte eine Shell, die mein Skript startet, und sonst nichts weiter.“ Die Shell brauchst du wohl, damit deine „weiteren, vorgegebenen Aktionen“ ausgeführt werden, von denen ich annehme, dass sie in deiner „~/.bash_logout“ oder ähnlich definiert sind.

xterm -e 'bash --login -c "/pfad/zu/deinem/skript.sh; exit"'

Andere Möglichkeit wäre, dein Terminal ganz normal zu starten und dann das Skript nicht in einer Subshell, sondern in der aktuellen laufen zu lassen und am Ende des Skripts explizit ein „exit“ zu setzen. Dazu dient der einzelne Punkt bzw. „source“ (– edit: Ja, „exec“ ist besser, dann muss es kein Shellskript sein).

. /pfad/zu/deinem/skript.sh

Vielleicht treffe ich aber auch zu viele Annahmen. Im Zweifel beschreibe mal genauer, was diese „vorgegebenen Aktionen“ sind, wodurch sie ausgelöst werden und so weiter. Denn die sind ja der Knackpunkt, nich’?

Ich würde auch sagen: Wenn Dir noch nicht geholfen ist, zeig doch mal eine abgespeckte Testkonstellation der 2 Skripts, die nur das Problem zeigen.

Eure Denkanstösse haben mich von einem gewaltigen "Denkknoten" zurückgeführt auf einen sehr einfachen, direkten Weg.

Das Problem ist im Prinzip nur durch meine Denkweise entstanden - jetzt läuft alles so, wei ich es möchte 😉

Vielen Dank an alle!

Gruß df8oe