Automatisch richtigen (Perl-) Interpreter aus PATH wählen

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.

 

Keine TrackBacks

TrackBack-URL: http://www.perl-blog.de/mt/mt-tb.cgi/246

Jetzt kommentieren

Aktuelle Kommentare

  • Niels Dettenbach: ...schade eigentlich, das es PyPerl nicht mehr wirklich gibt. Zwar weiter lesen
  • vTasker: Was ist das denn für ein MIST? Der Artikel ist weiter lesen
  • Alvar Freude: Nein, Susan, das ist falsch. XING wurde von der epublica weiter lesen
  • Susan: Hi, das ist eine komplett falsche Aussage. XING laeuft auf weiter lesen
  • Alvar Freude: Zu E.Doerr: Ich fange mal mit dem zweiten Punkt, dem weiter lesen
  • E.Doerr: Der Vergleich ist ganz interessant - aber wenn ich mich weiter lesen
  • Alvar: Die Universitäten sind sicherlich ein wichtiger Ansatzpunkt. Diese sind da weiter lesen
  • Ingmar Drewing: Das Problem - wenn man es denn so nennen will weiter lesen
  • Alvar Freude: Gut wäre auch, wenn sich mehr gestandene Entwickler für Perl weiter lesen
  • Martin Seibert: Ich wäre auch stark für den Nachwuchs! :-) weiter lesen

Über diese Seite

Diese Seite enthält einen einen einzelnen Eintrag von Alvar Freude vom 13.12.08 0:30.

TypePad AntiSpam: Bad Request und die Lösung ist der vorherige Eintrag in diesem Blog.

Liste der Vorträge für Perl-Workshop steht ist der nächste Eintrag in diesem Blog.

Aktuelle Einträge finden Sie auf der Startseite, alle Einträge in den Archiven.