Ich benutze meine eigene persönliche Umgebung, die seit über 20 Jahren konsequent funktioniert. Ich habe vor ca. 14 Jahren begonnen, viele Perl-Skripte zu integrieren. Ich habe den gleichen Baum von Befehlszeileninterpretern für 22 Jahre verwendet (NDOS- & gt; 4DOS- & gt; 4NT- & gt; TCMD, das gleiche Programm wirklich).
Ich habe gerade von ActiveState Windows Perl zu Strawberry Perl gewechselt.
Seit Jahren benötige ich nur noch ein Perl-Skript:
%Vor%So geben Sie an, mit welchem Programm die Dinge geöffnet werden sollen.
das kann ich einfach machen:
%Vor%Die Dinge haben einfach funktioniert. Für immer.
Heute, in einem einwöchigen Betriebssystem, haben die Dinge einfach aufgehört zu arbeiten.
Perl-Skripte werden ausgeführt, aber sie werden nichts tun. Kein Fehler. Keine Leistung. Nichts.
Der einzige Weg, wie es funktioniert, ist, wenn ich das Skript mit "perl" voranstelle (in diesem Fall wird mein Pfad nicht durchsucht, weil der Skriptname jetzt ein Parameter ist, so dass ich den vollständigen Pfad für ausfüllen muss) das Skript)
Hier ist, wie es ist, ich zu sein:
%Vor%Beachten Sie, dass dies gestern gut funktionierte, sogar heute noch. Ich weiß nicht, was das verändert hat und was es kaputt gemacht hat, und ich habe ziemlich lange nach ähnlichen, aber nicht identischen Problemen gesucht - und keine Lösung hat geholfen.
Ich habe eine Schiffsladung von Skripten. Ich würde es wirklich hassen, die Welt "perl" vor jedem von ihnen einfügen zu müssen, und dann den vollständigen Pfad zu qualifizieren!
Realistisch gesehen werde ich wahrscheinlich einen Perl.bat-Wrapper schreiben müssen, der den Dateinamen des Parameters in einen vollständig qualifizierten Pfad konvertiert und explizit perl aufruft.
Ich will das wirklich nicht tun. Das ist eine Ban-Aid-Lösung. Ich möchte verstehen, was falsch ist, Adresse ist, und es lösen.
Ich fange an, Windows 7 zu hassen ...
Ich denke, Ihr Problem ist höchstwahrscheinlich, dass die Verbindung zu .pl zu perl.exe unterbrochen ist.
Schauen Sie HKEY_CLASSES_ROOT \ .pl in der Registry hat es wahrscheinlich Perl (oder sagen FOO) Unterknoten darunter
Sehen Sie sich nun HKEY_CLASSES_ROOT \ Perl oder FOO an, falls dies der Fall ist.
Es sollte eine Shell \ Open \ command Taste
habenDas sollte ungefähr so aussehen
%Vor%Natürlich könnte der perl.exe Pfad auf Ihrem System anders sein. Das % * ist das wichtige Bit, das die Argumente, die Sie an Ihr Skript übergeben, an perl.exe
übergibtWenn Sie also "test.pl foo bar" in einem Befehlsfenster ausführen, ruft die Shell im Hintergrund tatsächlich
auf %Vor%Diese Art von Problem tritt auf, wenn Sie einfach eine * .pl-Datei im Windows Explorer auswählen und versuchen, sie mit perl.exe zu verbinden.
Als zusätzlichen Bonus, wenn Sie .PL zu PATHEXT-Umgebungsvariable hinzufügen, müssen Sie test.pl nicht einmal angeben. test ruft test.pl auf, wenn es sich zuerst im Pfad befindet: )
Windows Powershell
Fügen Sie in Windows Powershell die Umgebungsvariable PATHEXT hinzu (andernfalls wird das Skript in einem separaten CMD-Fenster ausgeführt).
Powershell wird jedoch keine Befehle ausführen, es sei denn, sie befinden sich in PATH (d. h. "." ist standardmäßig nicht in $ env: PATH, ein bisschen wie root unter Unix)
Also, um ein Skript auszuführen
%Vor%Am einfachsten ist es, das Powershell-Profil zu verwenden.
z.B. in C: \ Benutzer \ Benutzername \ Dokumente \ WindowsPowerShell \ Microsoft.PowerShell_profile.ps1
%Vor%Wenn Sie nicht möchten ./ (und beachten Sie, dies ist ein Sicherheitsrisiko), fügen Sie "." zum Pfad (ohne die Anführungszeichen)
%Vor%Dann können Sie einfach
tun %Vor% Sie können Ihre Dateierweiterung überprüfen, indem Sie mit der rechten Maustaste auf eine Datei .pl klicken, properties auswählen und auf die Schaltfläche "Öffnen mit" klicken (das ist XP, ich weiß nicht, wie es in Windows 7 aussieht). Es kann sein, dass Ihre Erweiterung auf den falschen Ort zeigt.
Tags und Links command-line windows perl prefix strawberry-perl