2012-08-06 17 views
5

Traditionell würde ich nur C:\perl\bin in meiner PATH-Variable haben, aber aufgrund von Versionskonflikten würde ich gerne verschiedene Perl-Versionen an den Standorten C:\Perl-versionXY\bin behalten und meine Perl-Skripte über direkt aufrufen C:\Perl-...\bin\perl.exe theScript.pl ausführen.Benötige ich das Perl bin-Verzeichnis im PATH, um Perl-Programme (unter Windows) auszuführen?

Dies ist eigentlich unter einem automatisierten System ausgeführt werden, wo wir bereits direktC:\perl\bin\perl.exe für alle Perl-Skripte aufrufen. (Aber C:\perl\bin ist auch in der PATH.)

verschiedene Perl-Versionen Seite-an-Seite zu erleichtern, würde Ich mag zu entfernen C-perl-ist aus dem PATH um sicherzustellen, dass wir es nicht tun jemals Nebenwirkungen von irgendwelchen Perl bezogenen PATH Einstellungen sehen.

Soll das funktionieren? Was ist mit Modulen, die zusätzliche DLL-Dateien benötigen (wie LibXML, für die LibXML.dll im bin-Verzeichnis von Perl benötigt wird)?

Ich werde Strawberry Perl Portable für die nebeneinander Versionen verwenden. (In der Readme-Datei werden einige PATH-Einstellungen erwähnt, aber nicht erwähnt, welche für welche verwendet wird.)

+0

meinst du 'C: \ bin \ perl', denn das würde viel mehr Sinn machen –

+1

@johncorbett: warum würde das mehr Sinn machen? Windows ist nicht unix, also hat es kein c: \ bin. C: \ perl \ bin macht vollkommen Sinn, IMHO – pavel

+0

Haha, ich denke, Unix ist nur so in meinen Kopf gebohrt, auch auf Windows benutze ich cygwin –

Antwort

1

Vorausgesetzt, dass alle DLLs im selben Verzeichnis wie die ausführbare Datei sind, sollte es normal funktionieren. Wenn nur ein Eintrag für Perl im Pfad vorhanden ist, müssen sich die DLLs im selben Verzeichnis wie die ausführbare Datei befinden (oder werden mit einer expliziten Logik gefunden), sodass Sie OK sein sollten. Wenn eine ausführbare Datei eine DLL lädt, wird zuerst nach dem Verzeichnis gesucht, das die ausführbare Datei enthält.

Wenn Sie in Schwierigkeiten geraten, wäre eine Option, eine Befehlsdatei für jede Version zu erstellen. Sie könnten diese verschiedenen Namen geben, wie perl58.cmd, perl514.cmd usw., sie alle in einem einzigen Verzeichnis ablegen und dieses Verzeichnis auf den Pfad setzen. In jeder Befehlsdatei, fügen Sie den Pfad das entsprechende Perl-Verzeichnis und dann Perl startet mit den Befehlszeilenargumenten:

setlocal 
PATH=c:\perl58\bin;%PATH% 
perl %* 

Hinweis Verwendung des setlocal Befehls so, dass die Änderung auf den Weg nicht zurück in der exportiert wird In dem Befehlszeilenfenster führen Sie die Befehlsdatei aus.

0

Ich würde das ablehnen, wenn Sie das Perl bin-Verzeichnis im PATH nicht haben und alles, was Sie ausführen, versucht, aufzurufen Programm, das im bin-Verzeichnis verweilt, ohne einen expliziten Pfad anzugeben (schlechte Praxis, aber das hält es nicht davon ab), dann erhalten Sie Fehler, und je nachdem, wie dieser Fehler behandelt wird, können sich Probleme ergeben, die subtil und schwierig sind debuggen.

Also ich sage, wenn Sie nicht einen sehr zwingenden Grund haben, es nicht hinzuzufügen (z. B. IT-Richtlinien, die es unerschwinglich schwierig und lästig macht, zu PATH hinzuzufügen), dann fügen Sie es hinzu.

+0

Nun, wenn ich zwei Perl-Versionen habe, eine sagt 5,8 und eine 5,14, kann ich nur sinnvoll eine davon zum (globalen) Pfad hinzufügen. Es wäre der falsche Weg für die andere Version. Es scheint also keinen Sinn zu machen, es dem (globalen) Pfad überhaupt hinzuzufügen, und es wäre leichter, es nicht im Pfad zu haben, als erforderlich zu sein, um es kontextabhängig zu setzen. –

+1

Auf Unix-Systemen ist es gängige Praxis, ausführbare Dateien mit Shell-Skripten zu verpacken, die die Umgebung konfigurieren, in der die ausführbare Datei ausgeführt wird. Gibt es einen Grund, warum Sie die Aufrufe Ihrer Perl-Programme nicht in Batch- oder PowerShell-Skripts umbrechen können? –