Gleichmacherei

Endlich ist die in Auftrag gegebene Website fertig. Aufatmen im Büro – doch die Ernüchterung folgt auf den Fuß: Die Webdesignerin hat unter Windows gearbeitet und es mit der Groß- und Kleinschreibung von Dateinamen nicht so genau genommen, denn auf ihrem Microsoftschen Testrechner sind index.htm, Index.htm und INDEX.HTM identische Schreibweisen für eine einzige Datei. Unix-Dateisysteme wie die unter Linux hauptsächlich verwendeten ext2fs und ReiserFS bestehen hingegen darauf, dass ein großes A und ein kleines a auch in Dateinamen völlig unterschiedliche Dinge sind.

Doch der Relaunch der Seiten soll fristgerecht erfolgen, und wer mag sich jetzt noch hinsetzen, um in mehreren Dutzend Dateien all die falschen A HREF-Angaben per Hand zu korrigieren? Stellt sich also die Frage, wie sich die ganze Geschichte automatisiert erledigen lässt.

Aufgabe abstecken

Ganz trivial ist die Aufgabe nicht, denn es gibt Einiges zu tun: Zunächst gilt es, alle Verweise zu finden, die rauszusuchen, die sich auf lokale Dateien beziehen, den entsprechenden Dateinamen samt Pfad zu extrahieren und zu überprüfen, ob sich an der passenden Stelle im Dateisystem ein File dieses Namens befindet.

Stimmen die Bezeichnungen der Datei im Link und im Dateisystem überein, haben wir nichts zu tun. Sind sie vollkommen verschieden, fügen wir am besten einen Kommentar ein, dass an dieser Stelle manuell nachbearbeitet werden muss. Unterscheiden sich beide Angaben nur in der Groß- und Kleinschreibung, passen wir den Dateinamen in der Linkangabe an.

Das sieht nicht nach etwas aus, was sich einfach mit ein paar Kommandozeilentools und ein paar Pipes lösen lässt. Ehe wir uns hier verrenken, machen wir es lieber richtig und schreiben ein kleines Skript.

Ein Shell-Skript, ein sed-Skript, ein awk-Skript, ein … – der Möglichkeiten gibt es viele, doch damit der Artikel nicht allzu lang wird, einigen wir uns auf ein Perl-Skript. Das bietet sich an, denn erstens müssen wir im Wesentlichen suchen und ersetzen, wobei uns die Perlschen regulären Ausdrücke die Arbeit erleichtern. Das ginge zwar auch mit sed, doch da wir das Vorhandensein der Dateien im Dateisystem überprüfen müssen, käme sed nur mit Hilfe anderer Shell-Tools zurecht. Perl hat hier Vorteile, da es als "richtige" Programmiersprache auch Funktionen zum Zugriff auf das Dateisystem kennt und zudem schneller als ein Shell-Skript ist.

awk spielt seine Stärken speziell dann aus, wenn man spaltenorientiert arbeitet, was wir in diesem Fall nicht wollen. Doch sei an dieser Stelle betont, dass der Einsatz eines bestimmten Werkzeugs für eine bestimmte Aufgabe immer von den persönlichen Vorlieben abhängt. Wenn dieses bei Ihnen Python oder Tcl heißt, ist das vollkommen in Ordnung.

Leider hat Perl auch Nachteile: Obwohl (oder gerade weil) es massenweise Manpages und Dokumentation im Web wie in Buchform gibt, ist das Finden von Hilfe zu einer bestimmten Aufgabe eine sehr zeitraubende Beschäftigung. Da Perl zudem "menschlich" sein will, indem es mehrere Schreibweisen für eine bei anderen Programmiersprachen feste Syntax zulässt, wird zwar das Schreiben von Perl-Code auf den ersten Blick einfacher, doch das Lesen speziell dann erschwert, wenn ein Perl-Skript von Leuten mit anderen Perl-Gewohnheiten stammt. Diese Vielfalt macht das Perl-Lernen natürlich nicht leichter.

Perlen im Einsatz

Doch alles Lamentieren nutzt nichts, wenn der Release-Termin für die neue Website wartet. Also ran an den Lieblingseditor und eine neue Datei erzeugt. Nennen wie sie in schönstem Denglisch cgks als Abkürzung für "change Groß-Kleinschreibung" (denn wer will schon ein Programm aufrufen, das mit einem "ä" wie "ändere" beginnt).

Wie bei jedem Skript fällt die erste Zeile leicht: Sie besteht aus einem speziellen "Kommentar", der besagt, welcher Interpreter hier seine Arbeit verrichten soll. Mit which perl finden wir heraus, in welchem Pfad der Perl-Interpreter sich befindet (vorausgesetzt, er ist installiert und das entsprechende Verzeichnis ist im Suchpfad eingetragen).

Damit hätten wir schon einmal

#!/usr/bin/perl

dastehen. Nur tut man sich beim Entwickeln von Programmen leichter, wenn der Interpreter auch ein bisschen mehr auf Fallstricke hinweist, als nur über echte Syntaxfehler zu meckern. Dazu sollte doch die Manpage Informationen hergeben. Doch man perl erklärt uns zunächst, dass das Perl-Manual "um den Zugriff einfacher zu machen in einzelne Sektionen aufgeteilt ist", die als extra Manpages zu erreichen sind.

perlrun             Perl execution and options

sieht nach der Sektion aus, die wir brauchen, um mehr über Optionen zu erfahren, die das Debuggen erleichtern. Tatsächlich: man perlrun erklärt eine Option -w (wie "warnen"; Listing 1 gibt die Erläuterung auf deutsch wieder), die für unsere Absicherung geeignet scheint.

-w   warnt vor Variablennamen, die nur ein einziges Mal
      vorkommen und Skalar-Variablen, die benutzt werden,
      bevor sie überhaupt gesetzt wurden. Gibt des Weiteren
      Warnungen aus, wenn Subroutinen mehrfach definiert,
      nicht definierte Datei-Handles referenziert werden oder
      auf nur-lesbare Datei-Handles geschrieben werden soll.
      Weitere Warnungen gelten Werten, die als numerische Werte
      benutzt werden, aber keine Zahlen sind, Arrays, die
      wie Skalare benutzt werden, Subroutinen, die mehr als
      100 Mal rekursiv aufgerufen werden und unzähligen
      anderen Problemen.