Unix und seine Tools (2)

Viele Unix-Dienstprogramme unterstützen die direkte Weiterverarbeitung von Eingabedaten anderer Programme, ohne daß diese Daten erst in Form von Dateien zwischengespeichert werden müssen. Statt dessen werden Informationen über "Pipes" übergeben. Auch über Shell-Scripte lassen sich Unix- Dienstprogramme kombinieren.

Die Anwendung von Pipes läßt sich besonders einfach in VerDbindung mit dem Kommando more demonstrieren:

ls -l /usr/lib | more

In diesem Beispiel wird mit ls eine ausführliche Auflistung aller Dateien im Verzeichnis lu@ lib abgerufen. Die so erhalte Daten werden jedoch nicht auf dem Bildschirm ausgegeben, sondern über eine Pipe an more übergeben. Bei dem Zeichen "1" handelt es sich um das sogenannte Pipe-Zeichen. Es weist die S an, die Ausgabedaten des Kommandos vor dem Pipe-Zeichen als Eingabedaten für das Kommando nach dem Pipe-Zeichen zu verwenden. more sorgt dafür, daß die von ls -/gelieferten Informationen nicht einfach ohne Halt über den Bildschirm huschen, sondern daß nach jedem gefällten Bildschirm auf einen Tastendruck gewartet wird. Statt more werden häufig auch andere Pager wie less oder pg benutzt. Sollen Ausgaben nicht auf dem Bildschirm oder in einer Pipe, sondern in einer Datei landen, erreicht man dies übrigens leicht mit einer Ausgabe umlenkung:

ls -l /usr/lib > DATEINAME

Ähnlich einfach lassen sich Daten aus einer Datei als Eingabedaten für ein Unix-Kommando verwenden.

Datenfilter

Dienstprogramme wie more, die einen Datenstrom entgegennehmen, ihn in irgendeiner Fo weiterverarbeiten und ansch ßend das Ergebnis ausge kommen unter Unix häufig Einsatz. Es handelt sich be sen Programmen um sogenannte Filter. Die Anwendungsbereiche für Filter sind überaus vielfältig. Daten lassen sich mit Filtern suchen, neu formatieren, sortieren oder analysieren. Dabei übernimmt jedes Filter-Programm meist nur eine einzige, recht eng umrissene Aufgabe. Kornplexere Operationen lassen sich leicht durch das Hintereinanderschalten mehrerer Filter realisieren:

ls -l /usr/lib | grep libX | more

Hier werden die von ls gelieferten Daten vor der Ausgabe auf dem Bildschirmmitgrepbearbeitet.grepdient primär dazu, Zeilen aus einem Datenstrom zu entfernen und nur Zeilen mit bestimmten Schlüsselwörtern (auch über reguläre Ausdrücke steuerbar) an die nächste Instanz weiterzuleiten. Im obigen Beispiel erreichen more lediglich noch die Zeilen der von ls erzeugten Daten, die die Zeichenfolge libx beinhalten. Liebt man sortierte Daten, kann man sort dazu einsetzen, Zeilen nach diversen Kriterien zu sortien:

ls -l /usr/lib | grep libX | sort | more

Wer die hier vorgestellten Beispiele kritisch betrachtet, wird natürlich feststellen, daß die durchgeführten Operationen in der Praxis wenig Sinn machen bzw. einfacher zu bewerkstelligen wären. Es geht bei allen Beispielen jedoch in erster Linie um das Prinzip.

Filter und Shell-Scripte

Mit Filtern läßt sich anschaulich demonstrieren, wie sich unter Unix mit nur einer Kommandozeile Manipulationen durchfuhren lassen, für die auf anderen Betriebssystemen bereits ein kleines Programm geschrieben werden müßte. Sogar ganze Dateisysteme lassen sich unter Erhalt aller Zugriffsrechte mit einem kurzen Einzeiler kopieren. Und selbst wenn eine Aufgabe so komplex wird, daß sie nicht mehr sinnvoll in einer überschaubaren Kommandozeile untergebracht werden kann, muß man unter Unix noch lange nicht zum Compilergreifen. Shell-Scripte erlauben es, die vorhandenen Dienstprogramme auch für umfangreichere Aufgaben zu kombinieren. Überhaupt steckt in der Kombination von Dienstprogrammen über Shell-Scripte eine der großen Stärken von Unix. Was genau ist aber nun ein ShellScript? Es handelt sich dabei um eine Datei, die wie ein Binärprogramm über ihren Dateinamen gestartet werden kann und eine Abfolge von Kommandos enthält, wie man sie per Hand eingegeben haben könnte. Ähnlich wie bei einer "echten" Programmiersprache lassen sich Bedingungen überprüfen und so Teile des Scripts in Abhängigkeit von bestimmten Kriterien ausfahren. Der Begriff Makro ist vielen gewiß läufiger und kommt der Sacl recht nahe.
Bearbeitet wird ein Shell-Sc wie könnte es anders sein, einer Shell. Dabei muß es sich nicht um die Shell handeln, die man für sich selbst als Umgebung ausgewählt hat, die also als login-Sheil in der Datei letclpasswd aufgeführt ist. Da es für Unix verschiedene Shells gibt [1], die bei ( Ausführung von Scripten nicht oder nur eingeschränkt kompatibel zueinander sind, kann man die Shell, die zur Ausführung eines bestimmten Shell-Scripts herangezogen werden soll, zu Beginn der ScriptDatei mit einer leicht kryptisch anmutenden Syntax festlegen:

#!/bin/sh oder #!/usr/bin/csh

Shell im Sinne eines Shell-Scripts kann ein beliebiges Programm sein, das mit den im Shell-Script aufgeführten Kommandos etwas anzufangen weiß. Neben Scripts, die von einer "echten" Shell wie sh, bash, oder tcsh ausgeführt werden, findet man recht häufig auch solche, die für die leistungsfähige Script-Sprache perl [2, 3] gedacht sind und etwa so eingeleitet werden:

#!/usr/local/bin/perl

Voraussetzung dafür, daß eine ScriptDatei Oberhaupt als Shell-Script gelten kann, ist, daß diese Datei als ausführbare Datei gekennzeichnet wird. Diesen Status erhält eine Datei durch chmod:

chmod +x script

Gestartet werden kann das Script anschließend durch die Eingabe seines Namens, wobei natürlich sichergestellt sein muß, daß sich die Script-Datei in einem derdurch die Environment-Variable PATH definierten Pfade befindet.

Was bin ich?

Es ist unbedingt zu beachten, daß ein Shell-Script niemals den Namen eines Systemkommandos erhalten darf. Mißachtet man di Regel, wird dies zu unerwünschten Effekten führen. Es passiert bei der Eingabe von SyStE mandos nämlich nicht mei was eigentlich anhand des Kornmandonamens zu erwarten wäre. Und gemäß Murphys Gesetz sucht man dann lange nach der Ursache für das Fehlverhalten bis einem irgendwann einfällt, daß nicht das gewünschte Systemkommando aufgerufen wurde, sondern das gleichnamige Shell-Script. Und dieses hat höchstwahrscheinlich eine ganz andere Aufgabe. Welches Kommando sich wirklich hinter einem bestimmten Namen verbirgt, läßt sichje nach Sheil durch Eingabe von _ _ KOMMANDO herausfinden. Ein Beispiel für die Shell tcsh:

which login kann ergeben login:
shell bullt-in command.

Benutzt man die tcsh, startet die Eingabe von login also nicht das Systemkommando login, sondern die Shell interpretiert dieses Kommando selber. (Was natürlich nicht heißt, daß in letzter Konsequenz nicht doch noch das Systemkommando login von der Shell aufgerufen wird.)

which || kann ergeben ls: aliased to ls -l

Hier wurde || als Shell-Alias definiert, d.h., bei der Eingabe von 11 führt die Shell ls -/aus.

which ps kann ergeben /usr/bin/ps

Hier liegt nun endlich ein Kommando vor, das sofort zur Ausführung eines Systemprogramms führt.

Häufig verwendete Filter

Bereits die wenigen Beispiele dürften gezeigt haben, welche weitreichenden Möglichkeiten Filter und Unix-Dienstprogramme im allgemeinen, kombiniert mit Shell-Scripten, bieten. Bei der Vielzahl der vorhandenen UnixFilter ist es kaum möglich, all diese Programme oder gar alle ihre Parameter zu kennen. Daher konnte dieser Artikel wieder einmal nur die Oberfläche dieserthematik ankratzen. Natürlich geben die manpages sowie die weiterführende Literatur Auffschluß über alles, was man wisssen sollte. Einige Filter sind besonders praktisch für die tägliche Anwendung, und daher sollte sich jeder Unix-Anwender über die wichtigsten Filterprogramme kundig machen. Es fiel bereits der Begriff "reguläre Ausdrücke", mit dem man unter Unix immer wieder konfrontiert wird. Reguläre Ausdrücke stellen Suchmuster dar, wie sie von vielen UnixTools unterstützt werden. Über reguläre Ausdrücke lassen sich nicht nur einfache Text-Strings suchen, die vielleicht noch mit den bekannten Wildcards "*" und "?" versehen sind. Reguläre Ausdrücke können nahezu beliebig komplexe Aufgaben übernehmen, wenn es um das Suchen und auch Ersetzen von Textinformationen geht. Mehr dazu in der nächsten Ausgabe.

US

Literatur:

[1] Konrad Heuer, "Reichhaltige Auswahl", !x 2196 [2] Randal L. Schwartz, "Leaming Perl-, 0 'Reilly & Associates, lnc.

[3] Larry Wall, Randal L. Schwartz, "Programming Perl", 0 'Reilly & Associates, lnc.



Aus: ST-Computer 03 / 1996, Seite 48

Links

Copyright-Bestimmungen: siehe Über diese Seite