Eine kleine Bitte: Ich lese jeden Tag die Perl-Fragen von Stack Overflow und antworte/trage wo ich kann; Heute brauche ich die Hilfe der Gemeinschaft!Was könnte dazu führen, dass Perl Systemaufrufe fehlschlagen?
Perl-Setup: Ich benutze Active Perl 5.8.8 unter Windows. Die Installation befindet sich auf dem lokalen Laufwerk unseres Abteilungsservers, das auch für das Netzwerk freigegeben ist. Alle Abteilungsbenutzer führen Perl auf ihren eigenen PCs aus, indem sie auf dieses im Netzwerk installierte Perl zeigen. Dies hat jahrelang funktioniert und verursacht kein Problem, aber es ist eine Information, die benötigt wird, um das Problem zu verstehen.
Der betreffende Server ist auch unser "Cron" (Scheduled Task) -Server, der eine Vielzahl von Automatisierungsaufgaben abwickelt. Plötzlich letzte Woche, Systemaufrufe in Perl-Skripten (auf dem Server) begann zu scheitern (Details unten). Zuerst vermutete ich eine beschädigte Perl-Installation, aber auf allen Client-PCs können immer noch dieselben Perl-Skripte ohne Probleme ausgeführt werden, was mich zu der Annahme verleitet, dass es sich um ein Serverproblem handelt. Ich habe den Server zweimal neu gestartet, und das Problem ist hartnäckig, also brauche ich Hilfe!
Hier sind einige Beispiele für die verschiedenen Art und Weise, dass Systemaufrufe versagen, zu Perl Einzeiler kocht:
% perl -e "system('dir')"
, dass ein „dir“ -Liste gedruckt werden soll, sondern öffnet sie eine Unterschale . Wenn ich "exit" tippe, kann ich die Subshell verlassen, und ich bin wieder in der ursprünglichen Shell (bestätigt durch Untersuchung des Shell-Verlaufs mit der NACH OBEN-Taste).
% perl -e "print `dir`"
Das hängt tatsächlich. Nichts passiert überhaupt. Wenn ich Ctrl-C, um den Prozess zu beenden, bekomme ich die Meldung "Beenden des Signals SIGINT (2)" und die DOS-Eingabeaufforderung kommt zurück. Aber alle zukünftigen Befehle in der DOS-Eingabeaufforderung (selbst wenn Sie nur die EINGABETASTE drücken) verursachen den Fehler "Der Prozess hat versucht, in eine nicht vorhandene Pipe zu schreiben.". Sie müssen die DOS-Eingabeaufforderung verlassen, da sie praktisch nutzlos ist.
Letztes Beispiel:
% perl -e "system('Z:/Scripts/rebuild.pl')"
'ebuild.pl' wird nicht als interner oder externer Befehl erkannt, bedienbare Programm oder Batch-Datei.
In diesem Fall wechselt Perl die Forward-Slashes (/) zu DOS/Windows Backslashes(), was es seit Jahren gut gemacht hat. Aber Perl interpretiert das "\ r" am Anfang des Dateinamens "rebuild.pl" als Wagenrücklauf (glaube ich) und sucht nach dem verbleibenden "ebuild.pl". Aufrufe an andere Skriptnamen, deren Zeichen nicht so falsch interpretiert werden können, führen dazu, dass (bei Verwendung von Backticks) Unter-Shells geöffnet werden (für System() -Aufrufe).
Ich bin nicht nur verwirrt - ich bin verzweifelt! Die "Cron" -Aufträge unseres Abteilungsservers sind momentan nutzlos, da wir viele Systemaufrufe verwenden.
Wieder glaube ich nicht, dass dies eine korrupte Perl-Installation ist, da die Netzwerkbenutzer gut laufen können. Also, was könnte auf einer einzelnen Maschine passieren (nicht an die Perl-Installation selbst gebunden), die dazu führen könnte, dass Perls Systemaufrufe fehlschlagen?
Umgebungseinstellungen, wie gewünscht:
ALLUSERSPROFILE=C:\Documents and Settings\All Users
APPDATA=C:\Documents and Settings\engmodem\Application Data
CDSROOT=Z:\Cadence\SPB_16.5
CDS_CONCEPT_NOSPLASH=TRUE
CDS_LIC_ONLY=1
CDS_SITE=Z:\Cadence\Sites\16.5
CHDL_LIB_INST_DIR=%CDSROOT%
CLIENTNAME=USENTUTTLJL3C
ClusterLog=C:\WINDOWS\Cluster\cluster.log
CommonProgramFiles=C:\Program Files\Common Files
COMPUTERNAME=CORPUSAPP5
ComSpec=C:\WINDOWS\system32\cmd.exe
CONCEPT_INST_DIR=%CDSROOT%
FP_NO_HOST_CHECK=NO
HOMEDRIVE=H:
HOMEPATH=\
HOMESHARE=\\PF1\HOME
ICMHOME=Z:\Software\PTC\INTERC~1
INSTDIR=%CDSROOT%
LOGONSERVER=\\ENGMAHO5
LSF_BINDIR=Z:\Software\LSF\bin
LSF_ENVDIR=\\hwc151\LSF_6.2\etc
MESSAGE=BROADCAST
NUMBER_OF_PROCESSORS=2
OA_PLUGIN_PATH=%CDSROOT%\Share\oaPlugIns
OS=Windows_NT
Path=C:\Program Files\Legato\nsr\bin;Z:\oracle\ora92\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\Windows Resource Kits\Tools\;Z:\Software\Perl\5.8.8\bin;C:\Program Files\Oracle\jre\1.3.1\bin;C:\Program Files\Oracle\jre\1.1.8\bin;C:\Program Files\Support Tools\;Z:\Software\LSF\bin;C:\Program Files\PHP\;C:\Program Files\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\EMC RepliStor;C:\GitStack\python;C:\GitStack\python\Scripts;C:\GitStack\git\cmd;Z:\Scripts;Z:\bin;Z:\Cadence\SPB_16.5\tools\bin;Z:\Cadence\SPB_16.5\tools\fet\bin;Z:\Cadence\SPB_16.5\tools\pcb\bin;Z:\Cadence\SPB_16.5\OpenAccess\bin\win32\opt
PATHEXT=.COM;.EXE;.BAT;.PL;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.VBS
PCB_LIBRARY=16
PERL5SHELL=cmd
PHPRC=C:\Program Files\PHP\
PROCESSOR_ARCHITECTURE=x86
PROCESSOR_IDENTIFIER=x86 Family 6 Model 29 Stepping 1, GenuineIntel
PROCESSOR_LEVEL=6
PROCESSOR_REVISION=1d01
ProgramFiles=C:\Program Files
PROMPT=$P$G
PULLUP_DIFF_PAIRS=TRUE
SESSIONNAME=RDP-Tcp#1
SystemDrive=C:
SystemRoot=C:\WINDOWS
TZ=EST5EDT
VISUALSVN_SERVER=C:\Program Files\VisualSVN Server\
WF_RESOURCES=Z:\oracle\ora92\WF\RES\WFus.RES
windir=C:\WINDOWS
Nicht sicher, wie relevant das ist, aber könnte es ein Erlaubnisfehler sein? Der Benutzer, der das Skript ausführt, verfügt nicht über die erforderlichen Berechtigungen zum Ausführen der Systembefehle? Nur ein Gedanke. –
Der Benutzer befindet sich in der lokalen Gruppe Administratoren, demselben Benutzer, unter dem die geplanten Tasks seit Jahren ausgeführt werden. – jimtut
Vielleicht ist diese Frage besser für ServerFault oder SuperUser geeignet? – TLP