[[:tux|{{ :linux.png?40|}}]] =====(Bash) Shell-Funktionen===== FIXME In >>Shell-Funktionen<< können wie in >>Shell-Skripte<< bestimmte Arbeitsabläufe zusammengefasst werden und durch das Ausführen der Funktion oder des Skripts abgerufen werden. So können zB häufig wiederkehrende Aufgaben in einem Skript einmalig als Funktion definiert werden und beliebig oft an beliebigen Stellen im Skript aufgerufen werden. Das spart Code und wirkt sich positiv auf die Lesbarkeit des Skripts aus. >>Shell-Funktionen<< können aber auch außerhalb eines Skripts in einer Shell erstellt und verwendet werden. Die allgemeine Syntax zur Deklaration einer Funktion lautet wie folgt: function_name() { Command 1 Command 2 ... } ====Gueltigkeitsbereich==== Eine >>Shell-Funktion<< wird von der laufenden Shell ausgeführt, es wird dabei kein Kind-Prozess erzeugt, sie ist somit Bestandteil des laufenden Prozesses. Das bedeutet, Sie können nicht auf die Funktion zugreifen, wenn Sie eine Sub-Shell starten. Sie können aber die Funktion mit dem ''>>export -f //function_name//<<'' exportieren, um Sie auch in einer Sub-Shell zur Verfügung zu haben: $ export -f //function_name// Das allein nutzt aber nichts, wenn Sie das System neu starten bzw. wenn Sie eine neue Shell starten. Um diese Funktion auch nach einem Neustart des Systems zur Verfügung zu haben, können Sie die Funktions-Definition in den Shell [[:tux:profile|Konfigurationsdateien]] (zB >>.profile<<) plazieren. Definieren Sie einen Shell-Funktions-Namen welcher bereits durch ein vorhandenes Programm belegt ist, führt dies nicht zu einer Fehlermeldung, denn beides ist möglich. Es wird jedoch in der laufenden Shell zuerst der Name der Funktion aufgelöst, dass andere Programm ist in dieser Session nicht mehr verfügbar bzw kann nur noch mit absoluten Pfad ausgeführt werden. ====Performance==== Eine >>Shell-Funktion<< wird von der Shell bereits beim Abschluss der Definition verarbeitet (preprocess) und im Speicher abgelegt. Dadurch beschleunigt sich der Aufruf bzw. der Ablauf einer Funktion gegenüber einem >>Shell-Skript<<, weil Letzteres erst während der Laufzeit übersetzt wird und das obendrein noch jedes Mal, wenn das Skript aufgerufen wird. Andererseits belegen viele Funktionen auch unnötig Speicher, wenn diese Funktionen nur sporadisch oder gar nur einmal gebraucht werden. Mit dem Kommando ''>>unset //function_name//<<'' wird eine Funktion wieder aus dem Speicher gelöscht, die Funktion ist dann nicht mehr gültig: $ unset //function_name// ====Variablen==== Da eine >>Shell-Funktion<< keine Sub-Shell aufruft, sondern in der Umgebung der >>Parent-Shell<< ausgeführt wird, kann diese auch auf deren Umgebungs-Variablen zugreifen und diese verändern. Anders ausgedrückt, eine in einer >>Shell-Funktion<< deklarierten Variable behält nach Ablauf der Funktion ihre Gültigkeit. Eine in einem >>Shell-Skript<< deklarierte Variable verliert idR nach Ablauf des Skripts ihre Gültigkeit. Ein Beispiel: Wir deklarieren eine Variable >>foo<< in einer Shell: $ foo=bar $ echo $foo bar Wir definieren eine Funktion >>printfoo()<< in der selben Shell, welche uns lediglich den Inhalt der Variablen >>foo< anzeigen soll und führen diese aus: $ printfoo() { echo $foo; } $ printfoo bar Wir erstellen in der gleichen Shell ein Shell-Skript >>printfoo.sh<<: #!/bin/bash echo $foo Und führen dieses aus: $ ./printfoo.sh Wie Sie sehen, sehen Sie nichts... Umgekehrt kann nun eine Variable in einer Funktion deklariert werden: $ setvar() { bar=foo } Und nach dem Ausführen auch außerhalb der Funktion darauf zugegriffen werden: $ setvar $ echo $bar foo ====Beispiel==== Kürzlich stand ich vor einer Aufgabe etwas komplexere Löschoperationen zu testen und habe mir dafür ein Testverzeichnis mit diversen Unterverzeichnissen und Dateien erstellt. Um immer wieder auf diesen Stand zurückzukehren habe ich mir das oberste Verzeichnis dieser Struktur als Tarball gesichert und konnte nun jedes mal, wenn ich die Löschoperation erneut an der gesamten Struktur testen wollte, dass Testverzeichnis löschen und anschließend den Tarball entpacken. Danach hatte ich wieder das Testverzeichnis mit dem gesamten ursprünglichen Inhalt. Soweit so gut aber ich musste nun nach jeder Löschoperation aus dem Verzeichnis wechseln, das Testverzeichnis löschen, den Tarball entpacken und wieder in das Testverzeichnis wechseln. Recht umständlich, dass sollte einfacher gehen... Folgende Funktion hat nun den gesamten Vorgang automatisiert: # rebuild() { cd ..; rm -rf master/; tar -xvf master.tar; cd master; tree } --- //pronto 2012/11/09 10:50// {{keywords>linux shell function ()}}