Es soll ja Leute geben, die selbst Programme entwickeln. Für mittelschwere Probleme reicht evtl. eine Scriptsprache. Infrage kämen da
- erweiterte Bat-Dateien ab Windows NT
- PowerShell ab WIndows XP (serienmäßig in Windows 7)
- C-Shell (Bash) unter Unix (Linux)
- Perl
Bat-Dateien bzw. C-Shell sind für komplexere Aufgaben nicht unbedingt leistungsfähig genug. Die PowerShell hat den Nachteil, dass das erworbene Know-How für Unix nicht wiederverwendbar ist. Als Möglichkeit bleibt also Perl. Python kann man natürlich auch unter Windows und Unix benutzen. Dieser Artikel will sich aber auf Perl beschränken.
Mittels der Editoren Ultraedit bzw. Notepad++ kann man Perl-Scripte in der Syntax einfärben lassen. Ein Test ist damit jedoch nicht möglich. Es bliebe nur die Methode aus der Computersteinzeit, Testausschriebe einzubauen. Eine bessere Möglichkeit ist natürlich eine integrierte Entwicklungsumgebung (IDE) mit Debug-Möglichkeit. Eine Variante dazu ist die Java-IDE Eclipse mit einem Plugin für Perl. Aufgrund ihres modulares Konzeptes kann Eclipse durch vielfältige Plugins erweitert werden.
Wir benutzen das vorhandene oder neu installierte Eclipse (Classic-Version). Dazu kann man das EPIC-Plugin online hinzufügen (näheres weiter unten). Unter Windows XP reicht dieses schon aus, um Perl-Scripte zu editieren und zu debuggen.
Bild 1: Ein Perl-Script
Unter Windows 7 kommt allerdings zunächst eine Fehlermeldung und es ist noch einiges an zusätzlichen Arbeiten nötig.
Bild 2: Fehlermeldung beim Perl-Debuggen
Wir sehen also eine Fehlermeldung, dass "perl5db.pl" nicht korrekt ausgeführt wurde. Dieses befindet sich unter Perl\lib und evtl. unter Perl\site\lib. Man könnte dies unter Windows 7 im Perl-Include-Pfad von Eclipse aufnehmen (näheres später). Trägt man dort gemäß MS-Konvention ein:
"c:\Program Files\Perl\lib" bzw.
%ProgramFiles%\Perl\lib
bekommt man eine Fehlermeldung "...Files not found...".
Die Syntax in Visual Studio wäre $(ProgramFiles)\Perl\lib.
Dazu fällt mir nur die Antwort an Mickey Kleinweich seit Windows 95 ein: "Ein Blank im Dateinamen ist der größte Schwachsinn, seitdem der Kaiser Caligula sein Pferd zum Konsul ernannt hat!"
Bei einem großen Kunden waren deutsche Umlaute und Blanks in Windows-Dateinamen verboten. Diese Regel hatte ich für mich aufgrund von Transfer-Erfahrungen schon vorher festgelegt. Kein mir bekanntes professionelles Betriebssystem (div. AEG / VMS / Ultrix / Solaris / TruUnix etc.) auf Midrange-Rechnern unterstützt solch einen Unsinn. In allen Programmiersprachen und diesen Betriebssystemen gilt ein "white space" als Trennzeichen für Namen! Unter Windows XP würde "c:\Programme\Perl" keine Schwierigkeiten machen in der deutschen Version. Die US-Version hat aber auch dieses blöde Blank!
Für Windows 7 installieren wir also Perl neu unter C:\Perl64. Die Verzeichnisbäume windows und die beiden "Program Files" sind durch UAC (Benutzerkontensteuerung) geschützt. C:\irgendeinName ist NICHT geschützt, daher c:\Perl64. Den Pfad für perl\bin und perl\site\bin müssen wir in die Environment-Variable "path" hinzufügen. Die Installation fragt danach. Nach der Perl-Installation muss noch der eigentliche Perl-Debugger "Padwalker" mit Online-Verbindung in einem Cmd-Fenster als Admin installiert werden:
$ c:\perl64> ppm install padwalker (als ADMIN!)
Downloading ActiveState Package Repository packlist...done
Updating ActiveState Package Repository database...done
Syncing site PPM database with .packlists...done
Downloading PadWalker-1.94...done
Unpacking PadWalker-1.94...done
Generating HTML for PadWalker-1.94...done
Updating files in site area...done
6 files installed
Durch $ perl –d meinScript.pl können wir prüfen, ob der Debugger grundsätzlich funktioniert. Verlassen der Eingabe erfolgt durch Ctrl-C bzw. Ctrl-Z.
Jetzt tragen wir in Eclipse bei dem Perl-Script unter dem Menüpunkt "Project / Properties / Perl Include Path" noch den neuen Pfad ein.
Bild 3: Perl-Pfad für die Datei "perl5db.pl"
Ein neuer Test zeigt, dass es immer noch nicht geht. Es kommt die gleiche Fehlermeldung wie oben. Eine Suche im Internet mit "perl debugger eclipse windows7" bringt einige Seiten mit Erklärungen. Man liest, dass der Perl-Debugger "Padwalker" die Ports ab 5001 benutzt und diese in der Firewall geöffnet werden müssen.
Bild 4: Firewall-Regel für Perl-Debugger "Padwalker"
Nach einem Neustart von Windows 7 erhalten wir endlich das gewünschte Ergebnis:
Bild 5: erfolgreicher Start des Perl-Debuggers in Eclipse
Falls jemand noch nie Plugins in Eclipse installiert hat, soll hier noch eine kurze Erläuterung gegeben werden. Man kann online Plugins von der Eclipse-Seite oder anderen Internetadressen installieren. Der Nachteil ist, dass man diese Plugins nicht wieder los wird und bei jeder neuen Eclipse-Version dieses wiederholen muss. Die Zeitschrift c't brachte dazu einen besseren Vorschlag:
Verzeichnis-Struktur für Eclipse-Plugins (ct 19/2007 S. 130)
...\Eclipse\myplugins\<name>\eclipse\features
...\Eclipse\myplugins\<name>\eclipse\plugins
...\Eclipse\links\<name>.link (LINK nicht LNK) mit Inhalt:
path=D:/eclipse/myplugins/name (mit Unix '/')
Man kann also die Verzeichnisse "myplugins" und "links" löschen, dann sind die Plugins wieder weg. Kopieren in die neue Eclipse-Version führt dazu, dass beide Versionen (oder mehrere Rechner) jetzt diese Plugins kennen.
Bild 6: Extra-Verzeichnis für Eclipse-Plugins zur besseren Handhabung.
Im Verzeichnis "links" muss jeweils für jedes Plugin eine Datei name.link (nicht .lnk) angelegt werden mit dem Installationsverzeichnis im Unix-Format.
Bild 7: Verzeichnis "links" mit Namen der einzelnen Plugins
Die meisten Plugins kommen im Zip-Format und müssen nur in die passende Struktur kopiert werden und danach den Pfad in die Link-Datei eingetragen werden. Das Epic-Plugin meint, es müsse ein wenig von dieser Regel abweichen, daher eine abweichende Syntax bei der Ausgabe des Type-Befehls.
Das hier Beschriebene funktioniert für Eclipse-Versionen "3.7 Indigo" und "4.2.1 Juno". Die Eclipse-Namen werden von den Entwicklern nach den Monden des Jupiters gewählt.