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
  • Alvar Freude: Kannte ich noch nicht, danke für den Hinweis; allerdings ist weiter lesen
  • Ben Sieverts: Ich vermisse noch folgendes Buch auf der List: Effective Perl weiter lesen
  • Alex: Ich schlage einfach mal ganz unverschämt bei diesem Beitrag die weiter lesen
  • Marcel: Oke, danke für den Tipp. Schade natürlich. Wird euer Buch weiter lesen
  • Alvar: Nein, leider ist das noch nicht fertig. :-( Es gibt weiter lesen
  • Marcel : Hallo! gibt es dein Buch zu Perl6 schon? Wo kann weiter lesen
  • air max 2009: Nimm ein Paradigma deiner Wahl (z.b. MVC) und lerne Applikationscode weiter lesen
  • vTasker: Was ist das denn für ein MIST? Der Artikel ist weiter lesen
  • Virenschutz-Test: Das ist ja lustig hihi. Der Admin ist wohl nicht 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.