Rheinwerk Computing < openbook > Rheinwerk Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

 << zurück
Shell-Programmierung von Jürgen Wolf
Einführung, Praxis, Referenz
Buch: Shell-Programmierung

Shell-Programmierung
782 S., mit CD, 44,90 Euro
Rheinwerk Computing
ISBN 3-89842-683-1
gp Kapitel 10 Fehlersuche und Debugging
  gp 10.1 Strategien zum Vermeiden von Fehlern
    gp 10.1.1 Planen Sie Ihr Script
    gp 10.1.2 Testsystem bereitstellen
    gp 10.1.3 Ordnung ist das halbe Leben
  gp 10.2 Fehlerarten
  gp 10.3 Fehlersuche
    gp 10.3.1 Tracen mit set -x
    gp 10.3.2 DEBUG und ERR-Signal
    gp 10.3.3 Variablen und Syntax überprüfen
    gp 10.3.4 Eine Debug-Ausgabe hinzufügen
    gp 10.3.5 Debugging-Tools

Kapitel 10 Fehlersuche und Debugging

Sicherlich haben Sie im Verlauf der vielen Kapitel beim Tippen und Schreiben von Scripts genauso viele Fehler gemacht wie ich und sich gefragt: Was passt denn jetzt wieder nicht? Auch hier gilt, dass Fehler beim Lernen nichts Schlechtes sind. Aber sobald Sie Ihre Scripts auf mehreren oder fremden Rechnern ausführen, sollte dies nicht mehr vorkommen. Daher finden Sie in diesem Kapitel einige Hinweise, wie Sie Fehler vermeiden können und, wenn sie bereits aufgetreten sind, wie Sie diesen auf die Schliche kommen.


Rheinwerk Computing

10.1 Strategien zum Vermeiden von Fehlerdowntop

Sicherlich, Fehler gänzlich vermeiden können Sie wohl nie, aber es gibt immer ein paar grundlegende Dinge, die Sie beherzigen können, um wenigstens den Überblick zu behalten.


Rheinwerk Computing

10.1.1 Planen Sie Ihr Script  downtop

Zugegeben, bei einem Mini-Script von ein paar Zeilen werden Sie wohl kaum das Script planen. Wobei ich persönlich schon die Erfahrung gemacht habe, dass ein geplantes Script wesentlich schneller erstellt ist als ein aus dem Kopf geschriebenes. Eine solche Planung hängt natürlich vom entsprechenden »Kopf« ;-) und dem Anwendungsfall ab. Aber das Prinzip ist einfach. Zuerst schreiben (oder kritzeln) Sie auf, was das Script machen soll.

Ein Beispiel: Das Script soll auf mehreren Rechnern eingesetzt werden und ein Backup der Datenbank erstellen. Das Backup soll hierbei in einem separaten Verzeichnis gespeichert und bei mehr als zehn Backup-Dateien soll immer die älteste gelöscht werden.

Auch wenn man sich bei den ersten Gedanken noch gar nicht vorstellen kann, wie das Script funktionieren bzw. aussehen soll, kann man trotzdem schon mit der Planung beginnen.

#---------------------------------------------------------------#
Plan zum Backup-Script:
1.) Prüfen, ob das Verzeichnis für das Backup existiert (test) und
    ggf. das Verzeichnis neu anlegen (mkdir)-
2.) Da mehrere Dateinamen (zehn) in einem Verzeichnis verwendet
    werden, einen entsprechenden Namen zur Laufzeit mit 'date'
    erstellen und in einer Variablen speichern (date).
3.) Einen Dump der Datenbank mit mysqldump und den entsprechenden
    Optionen erstellen (mysqldump).
4.) Den Dump gleich in das entsprechende Verzeichnis packen und
    archivieren (tar oder cpio).    !!! Dateinamen beachten !!!
5.) Ggf. Datenreste löschen.
6.) Verzeichnis auf Anzahl von Dateien überprüfen (ls -l | wc -l)
    und ggf. die älteste Datei löschen.
Notizen: Bei Fertigstellung crontab aktivieren – täglich um
         01.00 Uhr ein Backup erstellen.
#---------------------------------------------------------------#

Zwar haben Sie jetzt noch keine Zeile Code geschrieben, doch Sie werden feststellen, dies ist schon die halbe Miete. Und wenn Sie merken, dass Sie das Script mit dem derzeitigen Wissensstand nicht realisieren können, wissen Sie wenigstens, wo sich Ihre Wissenslücken befinden und können entsprechend nachhelfen.


Rheinwerk Computing

10.1.2 Testsystem bereitstellen  downtop

Bevor Sie Ihr Script nach der Fertigstellung dem Ernstfall überlassen, sollten Sie auf jeden Fall das Script lokal oder auf einem Testsystem testen. Gerade Operationen auf einer Datenbank oder schreibende Zugriffe auf Dateien sollte man möglichst vorsichtig behandeln. Denn wenn irgendetwas schief läuft, ist dies auf Ihrem Testsystem nicht so schlimm, aber bei einem oder gar mehreren Rechnern könnte Ihnen solch ein Fehler eine Menge Ärger, Zeit und vor allem Nerven kosten. Es wäre auch sinnvoll, wenn Sie mehrere verschiedene Testsysteme zum Ausprobieren hätten – denn was auf Ihrer Umgebung läuft, muss nicht zwangsläufig auch in einer anderen Umgebung laufen. Gerade wenn man häufig zwischen Linux und UNIX wechselt, gibt es hie und da doch einige Differenzen.


Rheinwerk Computing

10.1.3 Ordnung ist das halbe Leben  toptop

Hierzu gleich am Anfang folgendes Script:

# Eine Datei anlegen
# Name: creatfile
CreatFile=atestfile.txt
if [ ! -e $CreatFile ]
then
touch $CreatFile
if [ ! -e $CreatFile ] ; then
echo "Konnte $CreatFile nicht anlegen" ; exit 1
fi
fi
echo "$CreatFile angelegt/vorhanden!"

Zugegeben, das Script ist kurz und im Prinzip auch verständlich, doch wenn Sie solch einen Programmierstil über längere Scripts beibehalten, werden Sie allein bei der Fehlersuche keine große Freude haben. Was auf den ersten Blick negativ auffällt:

gp  Keine Einrückungen bei den if-Anweisungen; es fehlt einfach an Struktur.
gp  Mehrere Befehle in einer Zeile. Bei einer Fehlermeldung wird die Zeilennummer mit ausgegeben. Befinden sich darin mehrere Kommandos, wird die Fehlersuche erschwert.
gp  Hier wurde die MS-übliche »ungarische Notation« verwendet, welche in der Praxis sehr fehleranfällig sein kann. Hat man vergessen, wie die Variable »CreatFile« geschrieben wurde und man schreibt »creatfile« oder »creat_file«, ergibt sich schon ein Fehler. Wer schon einmal die Win32-API zur Programmierung verwendet hat, weiß, was ich meine.
gp  Die Faulheit hat gesiegt, der Anwender weiß nach dem Script immer noch nicht, ob eine Datei angelegt wurde oder bereits vorhanden ist.
gp  Kommentarlose Scripts sind schwer zu pflegen, besser den ein oder anderen (vielleicht überflüssigen) Kommentar hinschreiben als gar keinen.

Hier das Script jetzt in einem etwas lesbareren Stil:

# Eine Datei anlegen
# Name: creatfile2
# Datei, die angelegt werden soll
creatfile=atestfile.txt
# Existiert diese Datei bereits ...
if [ ! -e $creatfile ]
then                      # Nein ...
   touch $creatfile       # Datei anlegen ...
   # Jetzt nochmals überprüfen ...
   if [ ! -e $creatfile ]
   then
      echo "Konnte $creatfile nicht anlegen"
      exit 1   # Script erfolglos beenden
   else
      echo "$creatfile erfolgreich angelegt"
   fi
fi
echo "$creatfile vorhanden!"

Das sieht doch schon viel besser aus. Natürlich kann Ihnen niemand vorschreiben, in welchem Stil Sie Ihre Scripts schreiben, dennoch will ich Ihnen hier einige Hinweise ans Herz legen, mit denen Sie (gerade, wenn Sie vielleicht noch Anfänger sind) ein friedlicheres Shell-Leben führen können.

Variablen und Konstanten

Verwenden Sie einen sinnvollen Namen für eine Variable – mit »x«, »y« oder »z« kann keiner so recht was anfangen. Verwenden Sie bspw. Variablen in einer Funktion namens removing(), könnten Sie Variablen wie »rem_source«, »rem_dest« oder »rem_temp« verwenden. Hier gibt es viele Möglichkeiten, nur sollten Sie immer versuchen, dass Sie einer Variablen einen Namen geben, an dem man erkennt, was sie bedeutet – eine Variable benötigt also ein klar zu erkennendes Merkmal.

Außerdem sollten Sie Konstanten und Variablen auseinander halten. Ich bezeichne hier Konstanten nicht als Variablen, die mit typeset als »readonly« markiert wurden, sondern meine einfach Variablen, die sich zur Laufzeit des Scripts nicht mehr ändern. Ein guter Stil wäre es bspw., Variablen, die sich im Script nicht mehr ändern, großzuschreiben (wer hat hier was von C gesagt ;-)) und normale Variablen klein. So kann man im Script schnell erkennen, welche Werte sich ohnehin nicht verändern und welche Werte variabel sind. Dies kann die Fehlersuche eingrenzen, weil konstante Variablen nicht verändert werden und man in diesen auch keine falschen Werte vermutet (es sei denn, man gibt diesen Variablen gleich zu Beginn einen falschen Wert).

Stil und Kommentare

Hier gibt es nur eines zu sagen: Einmal mehr auf (ENTER) und eventuell mal auf die (häufig noch wie neue) Tabulatortaste zu drücken, hat noch keinem geschadet. Ich empfehle Ihnen, eine Anweisung bzw. ein Schlüsselwort pro Zeile zu verwenden. Dies hilft Ihnen, bei einer Fehlermeldung gleich die entsprechende Zeile anzuspringen und zu lokalisieren. Ebenfalls sollten Sie der Übersichtlichkeit zuliebe Anweisungs- oder Funktionsblöcke einrücken.

Das Problem mit einen kaum kommentierten Code kennt man zur Genüge. Ich hatte zum Beispiel früher sehr viel mit Perl zu tun. Nach einem Jahr Abstinenz (und vielen anderen Programmiersprachen) benötigte ich nur ein paar Zeilen aus einem Script, das ich mal geschrieben hatte. Leider habe ich den Code nicht kommentiert und so gestaltete sich das »Entschlüsseln« etwas längerer bzw. ich benötigte wieder den Rat anderer Personen. Mit der Verwendung von Kommentaren hätte ich mir einiges an Zeit gespart. Ebenso ist dies mit der Shellscript-Programmierung. Sie werden schließlich noch was anderes zu tun haben, als immer nur Shellscripts zu schreiben.

Und: Es gibt auch noch das Backslash-Zeichen, von dem Sie immer dann Gebrauch machen sollten, wenn eine Zeile mal zu lang wird oder wenn Sie Ketten von Kommandos mit Pipes verwenden. Dies erhöht die Übersicht ebenfalls enorm.



Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.

>> Zum Feedback-Formular
 << zurück
  
  Zum Katalog
Zum Katalog: Shell-Programmierung
Shell-Programmierung
bestellen
 Buchtipps
Zum Katalog: Shell-Programmierung






 Shell-Programmierung


Zum Katalog: Linux-Server






 Linux-Server


Zum Katalog: Das Komplettpaket LPIC-1 & LPIC-2






 Das Komplettpaket
 LPIC-1 & LPIC-2


Zum Katalog: Linux-Hochverfügbarkeit






 Linux-
 Hochverfügbarkeit


Zum Katalog: Linux Handbuch






 Linux Handbuch


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo





Copyright © Rheinwerk Verlag GmbH 2005
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


Nutzungsbestimmungen | Datenschutz | Impressum

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de