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

  • Anonym: Heute in einem Intranet irgendwo in Berlin: Es wurde bei weiter lesen
  • Alvar Freude: Da ist das leider nicht so ganz einfach, zumal ja weiter lesen
  • Dragan: Hey, mach doch das gleiche für das Paypal-Modul :) weiter lesen
  • pi: Und jetzt ist sogar schon perl 5.11 erschienen 8-) weiter lesen
  • Heiko J.: Murks - "mit einem _genaueren_ Blick" auf Padre sollte das weiter lesen
  • Heiko J.: Wie wär's mal mit einem Blick auf Padre? weiter lesen
  • Heiko Specht: Ich habs mal ein klein bisschen unter die Lupe genommen. weiter lesen
  • Anonym: Der Bundestag hat eine neue Seite, vielleicht magst du ja weiter lesen
  • Hans: Viele Danke für den nützlichen Tip, habe eben mich darüber weiter lesen
  • Egon Uhlenbach : Mittlerweile kann man diese Politik eh inne tonne kloppen. Wir 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.