Perlシステムコールの起動に失敗する原因は何ですか？

Question

小さなリクエスト：私は毎日Stack OverflowのPerlに関する質問を読んで、できる限り答えてください。今日私はコミュニティの助けが必要です！

Perlの設定：WindowsでActive Perl 5.8.8を実行しています。インストールは、私たちの部門サーバのローカルドライブにあります。ローカルドライブはネットワークにも共有されています。すべての部署ユーザは、このネットワークインストールされたPerlを指すことによって、Perlを自分のPCで実行します。これは何年も働いていて問題を引き起こしていませんが、問題を理解するために必要な情報です。

このサーバーは、さまざまな自動化タスクを処理する「cron」（スケジュールされたタスク）サーバーでもあります。突然先週、（サーバ上の）Perlスクリプトのシステムコールが失敗し始めました（以下の詳細）。最初は、Perlのインストールが壊れている疑いがありましたが、すべてのクライアントPCで問題なく同じPerlスクリプトを実行できるため、サーバーの問題だと思うようになりました。私は2回サーバーを再起動しました。問題は永続的です。したがって、私は助けが必要です！ここで

は、システムコールが失敗していることを様々な方法のいくつかの例は、あるPerlのワンライナーに煮詰め：

「DIR」のリストを印刷する必要があります

% perl -e "system('dir')" 

、代わりにそれはサブシェルを開きます。 「exit」と入力すると、サブシェルを終了して元のシェルに戻ります（UPキーを使用してシェル履歴を調べることで確認できます）。

% perl -e "print `dir`" 

これは実際にはハングします。全く何も起こらない。 Ctrl-Cを押してプロセスを終了すると、「シグナルSIGINT（2）で終了」というメッセージが表示され、DOSプロンプトが表示されます。しかし、DOSプロンプトの中のどんな将来のコマンド（ENTERを押すだけでさえ）は "プロセスが存在しないパイプに書き込もうとしました"というエラーを引き起こします。効果的に役に立たないので、DOSプロンプトを終了する必要があります。

最後の例は：

% perl -e "system('Z:/Scripts/rebuild.pl')" 

「ebuild.pl」は、内部または外部コマンド、 操作可能なプログラムまたはバッチファイルとして認識されていません。

この場合、Perlはフォワードスラッシュ（/）をDOS/Windowsのバックスラッシュ（）に切り替えます。これは何年もうまくいっています。しかし、Perlは "rebuild.pl"ファイル名の先頭にある "\ r"をキャリッジリターン（私が思う）と解釈し、残りの "ebuild.pl"を探しています。文字列が誤って解釈されないような他のスクリプト名への呼び出しは、上記のように（バッククォートを使用すると）開いているサブシェル（システムコール）に対してハングします。

私はこれに困惑していません - 私は絶望的です！当社の部門サーバの「cron」ジョブは、現在多くのシステムコールを使用しているため、今は役に立たない。

また、ネットワークユーザーがうまく動作できるので、これは壊れたPerlインストールではないと思います。それで、Perlのシステムコールがこのように失敗する可能性のある個々のマシン（Perlのインストール自体には関係ない）で何が起こる可能性がありますか？

環境設定は、要求通り：

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 

Answer 1

それは、この奇妙な行動の理由が誤っPERL5SHELL変数を定義した判明：cmd.exe（Windowsのシェルインタプリタは）適切に処理するためのいくつかのパラメータで呼び出されなければなりません - いくつかの更新後にパラメータが欠落していました。）

ちなみに、The DocではPERL5SHELL環境変数がまったく定義されていないと、Perlは通常、「cmd.exe/x/c」行をシェル実行可能ファイルとみなしていると言われています。

P.S.私はこのスレッドが本当に好きです：それはコメントの目的をはっきりと示しています。 ）