Inhaltsverzeichnis
Beschreibung: Prüfungskandidaten sollten in der Lage sein, existierende Shell Scripts anzupassen und einfache neue (ba)sh Scripts zu schreiben. Dieses Lernziel beinhaltet die Verwendung der Standard sh Syntax (Schleifen, Tests), das Verwenden von Kommandosubstitution, das Prüfen von Kommando-Rückgabewerten, Testen des Status einer Datei und Schicken von Mails an den Superuser unter bestimmten Bedingungen. Ebenfalls enthalten ist die Vorsorge, daß der korrekte Interpreter auf der ersten Zeile (#!) von Scripts aufgerufen wird. Weiters enthalten ist die Verwaltung von Speicherort, Eigentum und Ausführungs- und suid-Rechten von Scripts.
Die wichtigsten Dateien, Bezeichnungen und Anwendungen:
- while
- for
- test
- chmod
Das Programmieren der Shell
Der Shell ist es prinzipiell egal, ob sie ihre Anweisungen interaktiv über die Tastatur bekommt, oder ob sie diese Angaben aus einer Datei herauslesen soll. Es ist also möglich, mehrere Befehlszeilen in eine Datei zu schreiben, die dann von der Shell ausgeführt werden, als ob sie nacheinander eingegeben wurden.
Dabei gehen die Möglichkeiten der Shell aber weit über die Batch-Programmierung von DOS hinaus. Sie bietet echte Schleifen, vernünftige Ein/Ausgabe, flexible Variablen, Bedingungsüberprüfung und vieles mehr. Es ist sogar möglich, Funktionen zu nutzen und so genauso strukturiert zu arbeiten, wie es in modernen Hochsprachen üblich ist.
Shellscripts werden in der Systemverwaltung sehr gerne und häufig eingesetzt, weil sie sehr schnell und effizient Lösungen für häufig vorkommende Probleme ermöglichen. Das Programmieren der Shell ist aber eben eine richtige kleine Programmiersprache, es würde den Rahmen des Kurses sicher sprengen, wenn das hier ein kompletter Programmierkurs wäre. Im Folgenden werden alle wichtigen Elemente der Shellscripts beschrieben, die sichere Anwendung kommt aber sicher nur mit viel Praxis…
Das grundlegende Prinzip der Linux Shellscripts
Prinzipiell ist ein Shellscript nichts anderes als eine Textdatei, die einzelne Befehlszeilen enthält, die von der Shell nacheinander abgearbeitet werden. Jede Zeile, die nicht mit einem Doppelkreuz (#) beginnt, wird von der Shell als Befehlszeile interpretiert und ausgeführt. Zeilen, die mit dem Doppelkreuz beginnen werden als Kommentarzeilen bewertet und nicht ausgeführt. Die einfachste Form wäre also, eine Textdatei zu erstellen, die ein paar Unix-Befehle enthält, diese Datei unter einem bestimmten Namen zu speichern z.B. script1 und dann eine Shell aufzurufen und ihr diesen Namen als Parameter mitzugeben also etwa
bash script1
Das ist aber natürlich nicht die eleganteste Lösung, schöner wäre es ja, das Script direkt wie ein Programm aufrufen zu können. Dazu müssen wir dem Script einfach nur das Ausführungsrecht geben.
chmod +x script1
Wenn wir uns jetzt das Script mit ls -l ansehen, so hat es jetzt neben den bisherigen Zugriffsrechten auch das x-Recht. Es ist jetzt durch die Nennung seines Namens aufrufbar. (Näheres zu chmod auf der entsprechenden Handbuchseite und im Abschnitt 1.104.5 der Vorbereitung auf die LPI101 Prüfung.)
Das geht solange gut, solange wir immer mit der selben Shell arbeiten oder das Script keine Elemente enthält, die eine andere Shell nicht verstehen würde. Aber sobald wir in unserem Script ein paar bash-Spezialitäten einbauen würden und dann plötzlich mit der C-Shell arbeiten würden fielen wir auf die Nase.
Das Problem ist also, daß unser Script selbst noch keine Angaben enthält, von welcher Shell es ausgeführt werden soll. Aber keine Angst, auch hierfür gibt es eine einfache Lösung. Jede Shell unter jedem Unix versteht eine ganz spezielle Kommentarzeile.
Wenn ein Script in der ersten Zeile die Anweisung
#!Programm
aufweist, so startet jede Shell das Progamm und gibt ihm als Parameter den Namen des Scripts mit. Wenn wir also in Zukunft grundsätzlich als erste Zeile unserer Scripts schreiben:
#!/bin/bash
sind wir auf der sicheren Seite. Selbst wenn wir mit der C-Shell oder einem ganz anderen Kommandointerpreter arbeiten wird für die Abarbeitung unseres Scripts jetzt grundsätzlich die bash benutzt.
Ein häufiger Fehler ist es, daß ein Schreibfehler in diese erste Zeile gemacht wird. Wenn dann das Script ausgeführt werden soll, dann findet die Shell den Interpreter nicht, da der ja falsch geschrieben ist. Also bringt sie eine etwas mißverständliche Fehlermeldung:
bash: Scriptname: No such file or directory
Das könnte man jetzt mißverstehen und denken, die Shell hätte das Script nicht gefunden. In Wahrheit hat sie den Interpreter nicht gefunden…
Kommandozeilenparameter
Was wäre ein Shellscript, wenn wir ihm keine Parameter übergeben könnten? Natürlich bietet die Shell diese Möglichkeit, noch dazu auf eine sehr einfache Art und Weise.
Zunächst noch einmal die Erinnerung, was sind Kommandozeilenparameter? Wenn wir ein Script schreiben, das z.B. addiere heißt und das zwei Zahlen addieren soll, dann werden wir vom Anwender des Scripts erwarten, daß er die beiden zu addierenden Zahlen als Parameter übergibt, daß er also z.B. schreibt:
addiere 10 20
In diesem Fall wäre der Kommandozeilenparameter Nummer 1 also die 10, der Parameter2 die 20. Innerhalb der Shell können diese Parameter angesprochen werden mit $1 und $2. Unser Script könnte also folgendermaßen aussehen:
#!/bin/bash let ergebnis=$1+$2 echo $1 plus $2 ergibt $ergebnis
Spezielle Variablen für die Kommandozeilenparameter
Grundsätzlich unterstützt die Bourne-Shell bis zu neun Parameter ($1 – $9), die direkt angesprochen werden können. Die Bourne-Again-Shell (bash) kann bis zu 99 Parameter direkt ansprechen, indem die Nummern der Parametr oberhalb des neunten in geschweifte Klammern gesetzt werden (${10} – ${99}). Der Parameter $0 enthält, wie in allen anderen Hochsprachen auch, den Namen des Scripts, wie es aufgerufen wurde:
Script | Parameter1 | Parameter2 | Parameter3 | Parameter4 | … |
$0 | $1 | $2 | $3 | $4 | … |
Oft ist es gar nicht notwendig, die Parameter einzeln anzusprechen. Wenn wir z.B. einen Unix-Befehl umbenennen wollten, z.B. cp in kopiere, dann wäre es ja lästig, wenn wir innerhalb des Scripts die ganzen denkbaren Parameter einzeln angeben müssten. Dazu gibt es die Sonderform $@ und $*, die beide alle angegebenen Parameter bezeichnen. In unserem Script müßten also nur die Zeilen stehen:
#!/bin/bash cp $*
Egal, wieviele Parameter jetzt angegeben wurden, alle werden einfach durch das $* übermittelt.
Sehr häufig ist es notwendig zu erfahren, wieviele Parameter überhaupt angegeben wurden. Dazu dient die spezielle Variable $#.
Zusammenfassend existieren also folgende spezielle Variablen für die Kommandozeilenparameter:
${n} | Der nte Parameter bei mehr als 9 Parametern (nur bash) | |
---|---|---|
$@ | Steht für alle angegebenen Parameter | |
$* | Steht für alle angegebenen Parameter | |
$# | Steht für die Anzahl aller angegebenen Parameter |
Der Unterschied zwischen $* und $@ ist marginal und wird sehr selten gebraucht. Er bezieht sich nur auf die Frage, wie die Shell reagiert, wenn $* oder $@ in doppelten Anführungszeichen stehen.
Das | wird ersetzt durch | |
---|---|---|
„$*“ | „$1 $2 $3 …“ | |
„$@“ | „$1“ „$2“ „$3“ „…“ |
Der Befehl shift
Der Befehl shift verschiebt die ganze Kette der Kommandozeilenparameter um eines nach links. Das bedeutet, der Parameter 2 wird zum Parameter1, der Parameter3 zum Parameter2 usw. Der erste Parameter fällt weg. Damit kann eine unbestimmte Anzahl von Parametern bearbeitet werden, indem in einer Schleife immer nur der erste Parameter verarbeitet wird und anschließend der Befehl shift aufgerufen wird. Die Schleife wird solange wiederholt, bis keine Parameter mehr übrig sind.
Auch wenn die Schleifenkonstruktion noch unbekannt ist folgt hier ein Beispiel. Das folgende Script gibt alle eingegebenen Parameter untereinander aus:
#!/bin/bash while [ $# -gt 0 ] #Solange die Anzahl der Parameter ($#) größer 0 do echo $1 #Ausgabe des ersten Parameters shift #Parameter verschieben $2->$1, $3->$2, $4->$3,... done
Der Befehl set
Normale Variablen bekommen ihre Werte durch das Gleichheitszeichen. Die Konstruktion
Variablenname=Wert
ist aber für Kommandozeilenparameter nicht möglich. Es ist also verboten zu schreiben
1=Hans
um damit $1 den Wert Hans zu geben. Falls in seltenen Fällen es doch notwendig sein sollte, die Kommandozeilenparameter zu ändern, so kann das mit dem Befehl set erledigt werden. Allerdings können nur alle Parameter gleichzeitig verändert werden. set schreibt einfach die gesamte Parameterkette neu.
Das heißt, alle Parameter, die dem Befehl set übergeben werden, werden so behandelt, als wären sie dem Script übergeben werden. Die echten Parameter, die dem Script wirklich übergeben wurden fallen dadurch alle weg, auch wenn set weniger Parameter erhält, als dem Script mitgegeben wurden.
Diese Anwendung von set macht zum Beispiel Sinn, wenn wir ein Script schreiben wollen, das zwingend zwei Kommandoparameter braucht. Wenn wir am Anfang die Anzahl der Parameter überprüfen und merken, daß das Script keine Parameter bekommen hat, so können wir mit set voreingestellte Parameter definieren.
Bedingungsüberprüfungen
Eine der grundlegendsten Dinge beim Programmieren ist die Überprüfung von verschiedenen Bedingungen, um damit auf bestimmte Gegebenheiten zu reagieren. Die Überprüfung von Bedingungen hat in der Regel bei Programmiersprachen zwei verschiedene Formen, die if-Anweisung und eine Mehrfachauswahl. Beide werden von der Shell unterstützt.
Die if-Anweisung
Die einfache if-Anweisung
Grundsätzlich hat die if-Anweisung der Bourne-Shell eine sehr einfache Form. Nach dem if steht ein Befehl, der ausgeführt wird. Gibt dieses Kommando eine 0 als Rückgabewert zurück, so gilt die Bedingung als erfüllt und die Aktionen, die zwischen dem folgenden then und fi stehen werden ausgeführt.
if Kommando then Aktion Aktion ... fi
Natürlich sind die Aktionen auch wieder normale Unix-Befehle. Das „fi“, das den Block beendet, der durch „if … then“ begonnen wurde, ist einfach nur das „if“ rückwärts geschrieben.
Das Programm test
Damit es jetzt sinnvolle Möglichkeiten gibt, Bedingungen zu überprüfen brauchen wir ein Programm, das verschiedene Tests durchführt und jeweils bei gelungenem Test eine 0 als Rückgabewert zurückgibt, bei mislingenem Test eine 1. Dieses Programm heißt test und ermöglicht alle wesentlichen Bedingungsüberprüfungen, die für das Shell-Programmieren notwendig sind.
Damit wir nicht jedesmal schreiben müssen
if test ...
gibt es einen symbolischen Link auf das Programm test, der einfach [ heißt. Allerdings verlangt das Programm test, wenn es merkt, daß es als [ aufgerufen wurde, auch als letzten Parameter eine eckige Klammer zu. Damit ist es also möglich zu schreiben:
if [ ... ]
Wichtig ist hierbei, daß unbedingt ein Leerzeichen zwischen if und der Klammer und zwischen der Klammer und den eigentlichen Tests stehen muß. Es handelt sich bei der Klammer ja tatsächlich um einen Programmaufruf!
Die verschiedenen Bedingungsüberprüfungen mit test bzw. [
-r Dateiname
Die Datei Dateiname existiert und ist lesbar
-w Dateiname
Die Datei Dateiname existiert und ist beschreibbar
-x Dateiname
Die Datei Dateiname existiert und ist ausführbar
-d Dateiname
Die Datei Dateiname existiert und ist ein Verzeichnis
-s Dateiname
Die Datei Dateiname existiert und ist nicht leer
-b Dateiname
Die Datei Dateiname existiert und ist ein blockorientiertes Gerät
-c Dateiname
Die Datei Dateiname existiert und ist ein zeichenorientiertes Gerät
-g Dateiname
Die Datei Dateiname existiert und das SGID-Bit ist gesetzt
-k Dateiname
Die Datei Dateiname existiert und das Sticky-Bit ist gesetzt
-u Dateiname
Die Datei Dateiname existiert und das SUID-Bit ist gesetzt
-p Dateiname
Die Datei Dateiname existiert und ist ein Named Pipe
-e Dateiname
Die Datei Dateiname existiert
-f Dateiname
Die Datei Dateiname existiert und ist eine reguläre Datei
-L Dateiname
Die Datei Dateiname existiert und ist ein symbolischer Link
-S Dateiname
Die Datei Dateiname existiert und ist ein Socket
-O Dateiname
Die Datei Dateiname existiert und ist Eigentum des Anwenders, unter dessen UID das test-Programm gerade läuft
-G Dateiname
Die Datei Dateiname existiert und gehört zu der Gruppe, zu der der User gehört, unter dessen UID das test-Programm gerade läuft
Datei1 -nt Datei2
Datei1 ist neuer als Datei2 (newer than)
Datei1 -ot Datei2
Datei1 ist älter als Datei2 (older than)
Datei1 -ef Datei2
Datei1 und Datei2 benutzen die gleiche I-Node (equal file)
-z Zeichenkette
Wahr wenn Zeichenkette eine Länge von Null hat.
-n Zeichenkette
Wahr wenn Zeichenkette eine Länge von größer als Null hat.
Zeichenkette1 = Zeichenkette2
Wahr wenn Zeichenkette1 gleich Zeichenkette2
Zeichenkette1 != Zeichenkette2
Wahr wenn Zeichenkette1 ungleich Zeichenkette2
Wert1 -eq Wert2
Wahr, wenn Wert1 gleich Wert2 (equal)
Wert1 -ne Wert2
Wahr, wenn Wert1 ungleich Wert2 (not equal)
Wert1 -gt Wert2
Wahr, wenn Wert1 größer Wert2 (greater than)
Wert1 -ge Wert2
Wahr, wenn Wert1 größer oder gleich Wert2 (greater or equal)
Wert1 -lt Wert2
Wahr, wenn Wert1 kleiner Wert2 (less than)
Wert1 -le Wert2
Wahr, wenn Wert1 kleiner oder gleich Wert2 (less or equal)
!Ausdruck
Logische Verneinung von Ausdruck
Ausdruck -a Ausdruck
Logisches UND. Wahr, wenn beide Ausdrücke wahr sind
Ausdruck -o Ausdruck
Logisches ODER. Wahr wenn mindestens einer der beiden Ausdrücke wahr ist
Mit diesen Tests sind so ziemlich alle denkbaren Bedingungsüberprüfungen möglich, die in einem Shellscript notwendig sind.
Die erweiterte if-else Anweisung
Natürlich bietet die if-Anweisung auch eine Erweiterung zur normalen Form, die sogenannte if-else Anweisung. Es ist also möglich zu schreiben:
if [ Ausdruck ] then Kommandos else Kommandos fi
Die if-elif-else Anweisung
Um noch einen Schritt weiterzugehen bietet die if-Anweisung sogar ein weiteres if im else, das sogenannte elif, das wieder eine Bedingung überprüft:
if [ Ausdruck ] then Kommandos elif [ Ausdruck ] then Kommandos else Kommandos fi
Mehrfachauswahl mit case
Oft kommt es vor, daß eine Variable ausgewertet werden muß und es dabei viele verschiedenen Möglichkeiten gibt, welche Werte diese Variable annehmen kann. Natürlich wäre es mit einer langen if-elif-elif-elif… Anweisung möglich, so etwas zu realisieren, das wäre aber sowohl umständlich, als auch schwer zu lesen. Damit solche Fälle einfacher realisiert werden können, gibt es die Mehrfachauswahl mit case. Der prinzipielle Aufbau einer case-Entscheidung sieht folgendermaßen aus:
case Variable in Muster1) Kommando1 ;; Muster2) Kommando2 ;; Muster3) Kommando3 ;; ... esac
Zu beachten sind zunächst die Klammern, die das Muster abschließen. Das Kommando, das zum jeweiligen Muster passt muß mit zwei Strichpunkten abgeschlossen werden. Statt einem Kommando können nämlich auch mehrere Kommandos, durch Strichpunkt getrennt stehen. Nur die doppelten Strichpunkte machen der Shell klar, daß das Kommando für den bestimmten Fall jetzt fertig ist.
Der Abschluß mit esac ist wieder einfach das Wort case rückwärts geschrieben.
Programmschleifen im Linux Script
Programmierung, insbesondere die heute übliche Form der strukturierten Programmierung ist ohne Schleifen nicht möglich. Unter Programmschleifen versteht man eine Wiederholung eines Teils des Programms, bis eine bestimmte Bedingung erfüllt ist.
Die Shell bietet zwei Formen der Schleifen. die Kopfgesteuerte Schleife und die for-Schleife, die eine Liste abarbeitet.
Die kopfgesteuerte Schleife mit while
Die kopfgesteuerte Schleife überprüft vor jedem Schleifendurchgang die Bedingung, die festlegt, ob die Schleife tatsächlich nochmal durchlaufen werden soll. Im Extremfall wird diese Schleife also kein einziges Mal durchlaufen, wenn nämlich die Bedingung schon von vorneherein nicht wahr ist.
Als Bedingung wird wieder jedes Programm akzeptiert, das einen Rückgabewert liefert. Ein Rückgabewert von 0 bedeutet, die Bedingung ist wahr, jeder andere bedeutet unwahr. Wie bei der if-Anweisung wird hier meistens wieder das Programm test oder eben dessen abgewandelte Form [ benutzt. Die verschiedenen Überprüfungen wurden bei der if-Anweisung detailiert dargestellt.
Die prinzipielle Form der while-Schleife mit dem [-Programm als Bedingungsüberprüfung sieht dann so aus:
while [ Ausdruck ] do Kommandos... done
Die Listenschleife mit for
Eine Listenschleife durchläuft die Schleife so oft, wie die Liste Elemente hat. Bei jedem Schleifendurchlauf bekommt die Variable den Wert des jeweiligen Listenelements.
for Variable in Liste do Kommandos... done
Als Liste gilt dabei jede mit Leerzeichen, Tabs oder Zeilentrennern getrennte Liste von Worten. Damit diese Funktionsweise etwas klarer wird ein einfaches Beispiel:
#!/bin/bash for i in Hans Peter Otto do echo $i done
Diese Schleife würde also dreimal durchlaufen. Im ersten Durchgang bekommt die Variable i den Wert „Hans“, im zweiten „Peter“ und im dritten „Otto“. Die Ausgabe der Schleife wäre also einfach
Hans Peter Otto
Richtig interessant wird diese Schleife jedoch, wenn als Liste ein Jokerzeichenkonstrukt steht wie etwa *.txt – Die Shell löst dieses Konstrukt ja in eine Liste aller Dateien im aktuellen Verzeichnis auf, die auf das Muster passen. Die Schleife wird also sooft durchlaufen, wie es Dateien gibt, die die Endung .txt vorweisen…
Eine andere häufige Form der Anwendung ist die Abarbeitung aller Kommandozeilenparameter eines Shellscripts. Die Variable $@ bietet ja diese Parameter alle zusammen. Diese Schleife wird so oft benutzt, daß es dafür eine Sonderform gibt, statt zu schreiben:
for name in $@ do ... done
reicht es zu schreiben
for name do ... done
Eine große Stärke der for-Schleife ist es, als Liste die Ergebnisse eines Unix-Befehls einzugeben. Mit Hilfe der Kommandosubstitution ist es ohne weiteres möglich, die komplexesten Unix-Befehle einzugeben, die als Ergebnis eine Liste ausgeben und diese Liste dann in der Schleife zu verarbeiten.
So kann man beispielsweise eine Liste aller User, die dem System bekannt sind dadurch erhalten, daß man mit dem Befehl cut die erste Spalte der Datei /etc/passwd ausschneidet. Der Befehl würde folgendermaßen aussehen:
cut -d: -f1 /etc/passwd
Um die Liste, die dieser Befehl ausgibt, als Liste für die for-Schleife zu nutzen muß der Befehl ja nur in Grave-Zeichen gesetzt werden, also
#!/bin/bash for i in `cut -d: -f1 /etc/passwd` do echo $i done
Shellfunktionen
Shellfunktionen sind kleine Unterprogramme, die einen eigenen Namen haben. Sie können sowohl im Script, als auch in der interaktiven Shell verwendet werden. Hier ist natürlich die Funktionsweise innerhalb eines Scripts Objekt der Darstellung.
Die Syntax von Funktionen wurden bereits im letzten Kapitel beschrieben, hir nur noch ein paar Anwendungsbeispiele im Script.
Als (zweifellos sinnloses) Beispiel folgt hier ein kleines Script, das eine Funktion enthält, die von einem bestimmten Startwert zu einem bestimmten Endwert zählt. Start- und Endwert werden im Hauptprogramm erfragt, die eigentliche Aufgabe des Zählens erledigt die Funktion:
#!/bin/bash function zaehle_von_bis() { i=$1 # i bekommt den Wert des ersten Parameters while [ $i -le $2 ] # Solange i kleiner/gleich Parameter2 do echo $i # Ausgabe der Zahl i let i=$i+1 # i wird um 1 erhöht done } # Das Hauptprogramm read -p "Startwert: " zahl1 # Startwert einlesen read -p "Endwert: " zahl2 # Endwert einlesen zaehle_von_bis $zahl1 $zahl2 # Aufruf der Funktion mit den gelesenen Werten
Rückgabewerte überprüfen
Wenn innerhalb eines Scripts ein Befehl aufgerufen wurde, so kann es für den weiteren Ablauf sehr wichtig sein, ob der Befehl erfolgreich war oder nicht. Diese Frage beantworten uns die Rückgabewerte (exit-codes). Jedes Programm gibt dem Betriebssystem einen ganzzahligen Rückgabewert zurück, wenn es abgeschlossen ist. Ist dieser Wert 0, dann bedeutet es eine fehlerfreie Beendigung des Programms, in allen anderen Fällen bedeutet es einen Fehler.
Das Programm test beispielsweise nutzt diese Fähigkeit, um bestimmte Tests durchzuführen und die Ergebnisse als Rückgabewert (0 bedeutet Test war erfolgreich also wahr) zurückzuliefern.
Die Shell kennt drei Methoden, diesen Rückgabewert zu analysieren:
Eine häufig benutzte Zeile, die die dritte Möglichkeit ausnutzt ist
test -x /usr/bin/foo || exit
Wenn das Programm /usr/bin/foo nicht existiert und ausführbar ist, wird das Script mit exit beendet.
Mail an root unter bestimmten Bedingungen
Ein Script wird häufig automatisch abgearbeitet auch wenn kein User am Terminal anwesend ist. Wenn es jetzt eine Meldung an den Benutzer oder den Systemverwalter ausgeben will, bleibt nur das Mail-System. Oder es soll eine Nachricht an den Systemverwalter abschicken, wenn bestimmte Bedingungen erfüllt sind, auch hier ist die E-Mail die beste Methode. Dazu existiert der Befehl mail.
Dieser Befehl schickt eine Mail mit bestimmter Titelzeile an eine bestimmte Adresse. Die Mail selbst wird entweder aus einer Datei oder aus einem Here-Dokument von der Standard-Eingabe gelesen. Im Script ist die Form des Here-Documents am verbreitetsten:
mail -s Titel Adresse <<EOM Beliebige Textzeilen EOM
Alles, was zwischen den beiden EOMs steht, wird an die angegebene Adresse per Mail verschickt. Beinhaltet der Titel Leerzeichen, so muß er in Anführungszeichen gesetzt werden. Als Adresse für den Systemverwalter kann einfach root eingegeben werden:
#!/bin/bash Auslastung=`df /dev/hda1| grep ^/ |cut -c52-54` if [ $Auslastung -gt 90 ] then mail -s "Alarm: Platte bald voll" root <<EOM Hallo Systemverwalter. Die Platte /dev/hda1 ist bald voll. Sie ist zu $Auslastung belegt. Mach was!!! EOM fi
Es können aber auch Programme direkt ihre Ausgaben an mail weiterpipen, also etwa
df | mail -s "Ausgabe von df" root
In beiden Fällen wird eine Mail an root verschickt, im ersten Beispiel, wird eine Warnung an root weitergegeben, wenn die Platte /dev/hda1 voller als 90% ist, im zweiten wird einfach die Ausgabe von df gemailt.
Speicherort von Scripts
Scripte sind nur dann ausführbar, wenn sie innerhalb des Suchpfades liegen. Bei der Wahl einer geeigneten Stelle für eigene Scripts sollte unterschieden werden, wofür sie gedacht sind.
Soll nur der Systemverwalter diese Scripts ausführen dürfen, dann empfiehlt es sich,
- die Scripts entweder in /usr/local/sbin oder /root/bin abzuspeichern. Beide Verzeichnisse liegen nur im Suchpfad des Systemverwalters.
- die Zugriffsmodi auf 700 zu setzen (rwx——), und dafür zu sorgen, daß sie root gehören. Somit kann sie nur root ausführen.
Sollen sie aber von allen Usern ausführbar sein, so sollten sie nach /usr/local/bin gelegt werden und den Zugriffsmodus 755 (rwxr-xr-x) besitzen. /usr/local/bin ist im Suchpfad aller User.
Grundsätzliche Vorsicht ist mit der Verwendung des SUID-Bits angeraten. Die Shell reagiert aber seit einigen Jahren sehr vorsichtig darauf und bezieht sich ihre Informationen über die Identität nicht aus der Effektiven UID sondern aus der echten UID. Ältere Versionen können hier aber erhebliche Schwierigkeiten machen…