Wozu ist Shellprogrammierung gut, und wozu nicht?

Mit Hilfe eines Shellprogramms kann man viele Dinge im Alltag schnell und einfach erledigen. Fast alles, was im interaktiven Betrieb aufwendig ist (Umbenennen von vielen Dateien nach einem bestimmten Strickmuster, Änderungen von Texten nach festen Regel, ...) kann man in einem Shellprogramm effektiver machen.

Vorteile eines Shellprogramms:

• Direktes Arbeiten, da die Programme nicht kompiliert werden, sondern nur interpretiert. Kleine Programme können sehr schnell erstellt und getestet werden.

• Wenn man sich auf den standardisierten Sprachumfang beschränkt, sind die erstellten Programme innerhalb der Unix-Welt sehr portabel.

  Shellprogramme funktionieren im günstigsten Fall unabhängig von Betriebssystem und darunter liegender Hardware.

  Stellenweise kann man sich mit einem Shellprogramm auch über Unix hinauswagen: Für Windows 95/98/NT existiert eine angepaßte Version der bash, die anstelle der schwachbrüstigen MSDOS-Eingabeaufforderung ziemlich alles beherrscht, was man von einer Unix-Shell erwartet. Unter Windows halt deutlich langsamer als unter Linux, aber es geht⁴.

• Auch wenn man in einem Shellprogramm eigentlich nicht mehr machen kann, als beim interaktiven Arbeiten, hat die Sache gegenüber dem direkten Arbeiten einen wesentlichen Unterschied: Der Ersteller des Shellprogramms muß nicht identisch sein mit dem Anwender.

  Wenn beispielsweise ein reiner Anwender, der von den Details eines Unixsystems recht wenig weiß, irgendwelche kryptischen Kommandos eingeben müßte, dann kann ein Shellprogramm sehr nützlich sein: ein Unixkundiger legt die nötigen Befehle in einem Skript ab, und der Unixunkundige (oder gegebenfalls mehrere) können das Skript nutzen, ohne es zu verstehen zu müssen.

  Auch wenn Ersteller und Anwender die selbe Person sind, kann das von Vorteil sein: Wenn man für eine gelegentlich auftretende Arbeit eine ziemlich komplizierte Kommandos zusammenbauen muß, hat man die Details bis zum nächsten Mal vielleicht schon wieder vergessen. Gießt man seine Erkenntnisse aber gleich beim ersten Mal in ein Shellprogramm, dann kann man es beim nächsten Mal einfach aufrufen. Gerade für vergeßliche Menschen wie mich ist das Gold wert. Beispiel: Audio-CD unter Linux kopieren. Dazu muß man mit einer länglichen Kommandozeile vom Original die einzelnen Tracks auf die Festplatte kopieren, und wieder mit einer kryptischen Kommandozeile auf einen Rohling brennen. Anfangs mußte ich jedesmal wieder nachdenken, wie das denn nun genau ging, und hatte es bis zur nächsten CD zwei Wochen später wieder vergessen. Jetzt habe ich ein Shellprogramm, das die einzelnen Tracks auf die Platte kopiert, und dabei gleich ein weiteres Shellprogramm generiert, mit dem man den Rohling brennen kann. Jetzt muß ich nur noch jedesmal das Shellprogramm wiederfinden.

• Eine Erweiterung dieses Gedankens berührt die Systemsicherheit. Angenommen, ein normaler Benutzer muß für irgendeine Arbeit manchmal eine (kostenpflichtige) Wählverbindung zum Onlineprovider aufbauen. Die Firma möchte aber nun erreichen, daß dieser Verbindungsaufbau ausschließlich für eine bestimmte Funktion im Zusammenhang mit der Arbeit möglich sein soll. Wenn man jetzt dem Benutzer generell den Aufbau der Verbindung ermöglicht, könnte er natürlich nach Belieben auch für andere Zwecke die Verbindung herstellen, sei es absichtlich oder unabsichtlich.

  Ein ähnlicher Fall ist gegeben, wenn normale Anwender (ohne Administratorfunktion) für ganz bestimmte Zwecke auf ein Bandlaufwerk zugreifen müssen, um beispielsweise Daten an ein Band anzufügen, ohne die bereits auf dem Band befindlichen Daten löschen zu dürfen. Gibt man ihnen die Berechtigung dazu direkt (beispielsweise nach Setzen von chmod 777 /dev/tape /dev/ntape), können sie versehentlich oder absichtlich auch das Band an den Anfang spulen, und damit vorhandene Daten (vielleicht Daten anderer Benutzer?) beim nächsten Schreiben zerstören.

  In solchen Fällen kann ein Administrator (root) ein Skript erstellen, mit dem nur die beabsichtigten und zulässigen Aktionen möglich sind (Daten auf ein Band nur schreiben, wenn es an das Ende gespult ist beispielsweise). Dieses Shellprogramm kann so installiert werden, daß es mit root-Rechten läuft, aber von normalen Benutzern gestartet werden darf. So braucht der Benutzer selbst keine Rechte haben, um das Bandlaufwerk anzusprechen, oder eine Onlineverbindung herzustellen, und kann es indirekt über das Shellprogramm doch - soweit das Shellprogramm es zuläßt.

Nachteile:

• Da die Programme im Quelltext vorliegen müssen, sind sie leicht kopier- und manipulierbar. Das kann in einem kommerziellen oder sicherheitsrelevanten Umfeld kritisch sein.

• Größere Projekte sind schwer zu debuggen.

• Durch das Interpretieren zur Laufzeit können Programme sehr langsam werden.

Entsprechend dieser Vor- und Nachteile kann man im Einzelfall abschätzen, ob sich ein Shellprogramm lohnt.

Trotz der vielen Programmiersprachen ist die eierlegende Wollmilchsau noch nicht erfunden. Shellprogramme sind oft nützlich, in vielen Fällen gibt es bessere Möglichkeiten. Vor allem, wenn ein Programm droht etwas aufwendiger zu werden, dann fährt man mit Perl oder mit kompilierten Programmen oft besser.

Typische Anwendungsfälle sind:

• kleine Hilfsprogramme, die recht eng mit den vielen Unixkommandos verzahnt sind (sed, grep, find, awk ...)
• Installationsprogramme, Setupprogramme, Konfigurationsprogramme
• einfache automatische Textverarbeitung (in Quelltexten Adressen anpassen, Suchen nach Schlüsselwörtern)
• komplexe Programmaufrufe je nach System für den einfachen Anwender erleichtern (X-Windows starten, Netscape aufrufen)

Sicher ungeeignet ist die Shellsprache um:

• ein Zeichenprogramm zu bauen
• ein Finite-Elemente-System zu bauen
• einen C++-Compiler zu implementieren