Das Skript folgt mit der Systemfunktion »readlink()« dem als Parameter überreichten Link und wiederholt dies so lange, bis das Ergebnis kein Link mehr ist. Die Funktion »dirname()« aus dem Modul File::Basename extrahiert aus dem resultierenden Pfad das Verzeichnis und Zeile 16 gibt es auf der Standardausgabe aus, wo die Bash-Funktion »lcd()« es aufschnappt, dorthin wechselt, es mit »pwd« ausgibt und mit »ls« die dort liegenden Einträge auflistet.
Sparsamer CPAN-Installierer
Kaum ein Perl-Snapshot kommt ohne zusätzlich zu installierende CPAN-Module aus. Üblicherweise klappt dies ja auch kurz und schmerzlos mit einer CPAN-Shell, die entweder mit »perl -MCPAN -eshell« aufrufbar ist oder mit dem neueren Perl-Distributionen beiliegenden Skript »cpan« .
Allerdings führt der Ressourcenhunger der CPAN-Shell auf Billighost-Accounts schnell zum Rauswurf. Abbildung 2 zeigt, was schon nach einigen Sekunden auf meinem Shared-Hosting-Provider Dreamhost passiert, ohne dass die CPAN-Shell auch nur das gewünschte Modul vom CPAN geladen hätte. Angeblich verbraucht es zu viel RAM-Speicher, und damit die anderen Shared Accounts nicht leiden, zieht Dreamhost – wohl etwas übereilt – die Notbremse.
Abbildung 2: Zu viel für einen Billighoster: Eine CPAN-Shell zum Installieren eines Perl-Moduls führt zum Ziehen der Notbremse.
Rettung naht in Gestalt des CPAN-Moduls App::cpanminus. Abbildung 3 zeigt die kurze Ausgabe des unscheinbaren Tausendsassas, der so wenig Ressourcen verbraucht, dass es selbst meinem Hoster mit seinen strengen Richtlinien nicht auffällt. Wie sein großer Bruder »CPAN.pm« weiß auch »cpanminus« mit lokalen Modulpfaden umzugehen.
Abbildung 3: Das Ressourcen-schonende CPAN-Modul App::cpanminus installiert mit »cpanm« problemlos das gewünschte Modul.
Damit der User CPAN-Module mit einem nicht privilegierten Account installieren kann und auch nicht die heilige Ordnung des Paketmanagers durcheinanderbringt, raten Experten dringend dazu, »local::lib« zu verwenden, falls die eingesetzte Linux-Distribution benötigte Perl-Module nicht im Repository führt.
Das Modul »local::lib« installiert der Admin, ein letztes Mal als Root, am geschicktesten mit Hilfe des Paketmanagers, unter Ubuntu zum Beispiel folgendermaßen:
sudo apt-get install liblocal-lib-perl
Erlaubt ein Hoster keinen Rootzugriff und lässt sich auch nicht erbarmen, das nützliche »local::lib« per Admin-Eingriff nachzuinstallieren, lädt der Benutzer den Tarball selbst vom CPAN, entpackt ihn und ruft
perl Makefile.PL --bootstrap make install
auf. Künftig mit einer CPAN-Shell installierte Module landen dann im Verzeichnis »perl5« unter dem Heimverzeichnis des unprivilegierten Users. Wenn dieser anschließend noch das Kommando
eval $(perl -I$HOME/perl5/lib/perl5-Mlocal::lib)
in die Startup-Datei seiner Shell einhängt, normalerweise ».bashrc« , setzt es die Variablen »PERL_MM_OPT« und »PERL5LIB« . Das bewirkt einerseits, dass sowohl die CPAN-Shell als auch »cpanminus« bei »make install« neu installierte Module lokal im Homeverzeichnis installieren. Andererseits finden aufgerufene Skripte, die neu installierte Module mit »use XXX« einbinden, diese dann auch. Falls die Skripte (etwa als Cronjob) nicht über die Environment-Variablen aus ».bashrc« verfügen, tut es auch ein explizit eingetragenes »use local::lib« im Programmcode vor dem Laden der benötigten lokal installierten Module.
