Neues in der Kategorie Tipps

Ein häufiges Problem: auf dem Entwicklungssystem hat man ein Perl zum Beispiel unter /usr/local/bin/perl installiert, und ein Programm soll ganz normal mit ./programm.pl gestartet werden.

Kein Problem, da passt man die Shebang-Zeile einfach entsprechend an:

#!/usr/local/bin/perl

use strict;
use warnings;

use Projekt::App;

Projekt::App->run(@ARGV);

Auf dem Produktionssystem liegt das Skript aber unter /usr/bin/perl oder /usr/local/projekt/perl/bin/perl. Ein Leser fragte nun: Was tun?

TIMTOWDI, es gibt mindestens zwei Möglichkeiten:

Richtiges Perl zur Laufzeit finden mit env

Das Programm env(1), auf nahezu jedem Unix/Linux-System vorhanden, kann ein Programm im aktuellen Pfad PATH suchen und entsprechend starten. Das kann man dann in die Shebang-Zeile aufnehmen.

#!/usr/bin/env perl

use strict;
use warnings;

use Projekt::App;

Projekt::App->run(@ARGV);

env hat noch eine reihe weiterer Optionen, so kann man eine Auswahl an Suchpfaden vorgeben und so weiter. Näheres sagt die Dokumentation zu env.

Der Perlige Weg mit Module::Build

Allgemein bietet sich der Einsatz von Module::Build meistens sowieso an. Wenn man dann auf dem Zielsystem die Applikation mit ./Build install installiert, werden nicht nur die Module in die richtigen (oder angegebenen) Verzeichnisse kopiert, sondern alle Skripte in bin/, die Perl in der Shebang-Zeile starten, aufs jeweils aktuelle Perl angepasst und installiert. Aus dem ersten Beispiel oben wird dann, so dass es auch funktioniert, wenn es als Shell-Skript ausgeführt wird:

#!/opt/local/bin/perl

eval 'exec /opt/local/bin/perl  -S $0 ${1+"$@"}'
    if 0; # not running under some shell

use strict;
use warnings;

use Projekt::App;

Projekt::App->run(@ARGV);

Unter Windows werden dann sogar gleich passende .bat-Dateien angelegt, mit denen das jeweilige Skript gestartet wird.

Der Unterschied zwischen den beiden Versionen ist im Wesentlichen, dass bei der Verwendung von env der jeweilige Nutzer bzw. Aufrufer mit seinem PATH den Perl-Interpreter bestimmt, während bei Module::Build dies von demjenigen, der das Skript/Programm installiert hat bestimmt wurde. (danke, tinita, für den Hinweis)

Bei Verwendung von ExtUtils::MakeMaker klappt das übrigens auch, aber man sollte bei neuen Projekten lieber Module::Build nutzen.

Bei Stackoverflow gibt es eine Liste mit Hidden features of Perl. Auch wenn sie nicht wirklich versteckt sind – fast alles ist ordentlich dokumentiert – sind doch viele Sachen dabei, die man nicht jeden Tag nutzt. Auf jeden Fall lesenswert!

Perl-Programmierer sind es gewohnt, sich die Arbeit durch viele schöne Konstrukte stark zu erleichtern. Manche davon wenden viele einfach an, ohne sich Gedanken darüber zu machen. Eines davon ist die Autovivification – zu Deutsch etwa „automatische Belebung“, da Referenzen automatisch zum Leben erweckt werden. Und die kann auch noch einiges mehr, als man glaubt.

Häufig muss man mit mehr oder minder vollständigen Eingabedaten in komplexen Datenstrukturen arbeiten, will aber dennoch sicherstellen, dass alles korrekt funktioniert bzw. keine Warnungen über undefinierte Variablen erhalten. Größere if-Blöcke sind da dann die Folge. Bei Perl sind diese aber oft unnötig. Denn Perl bietet – im Gegensatz zu beispielsweise Python, PHP, Ruby, Java oder C – mit der Autovivification die Möglichkeit, beim Zugriff auf komplexe Datenstrukturen viel Code zu sparen, den Code damit kompakter, übersichtlicher und robuster zu gestalten. Wer Bullshit-Bingo spielen will, darf es auch „Win-Win-Situation“ nennen.