一部のperlファイルで一貫性がなく、不可解な動作があります

Question

ホストはLinuxです。私は同じディレクトリに複数のファイルがあります。 *.plファイルはすべてコメントだけが異なる先頭に次が含まれています。

#!/usr/bin/perl -w 

BEGIN { chdir('/home/httpd/vhosts/mysite.com/httpdocs/newsbot'); unshift(@INC, "/home/httpd/vhosts/mysite.com/httpdocs/newsbot"); } 

use Form; 
use File; 
use Mysite; 

#Read in All Form Variables 
&ReadInForm; 

ファイルForm.pmはReadInFormサブルーチンと他には何が含まれています。

sub ReadInForm { 
}  
1; 

奇妙なことは、上記の出力が完全に矛盾していることです。時にはそれが細かい実行されますが、スクリプトの末尾に「内部サーバーエラー」メッセージを表示し、error_logファイルに次のようになります：

引数には、「」は/ usr/lib64のでサブルーチン・エントリの数値ではありません/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi/ModPerl/RegistryCooker.pmライン171 \ nは、リファラ：http://www.mysite.com/newsbot/groupkeywords.pl

他の回では、それは次のコマンドを実行し、出力されませんブラウザ：

未定義のサブルーチン& ModPerl :: ROOT :: ModPerl ::レジストリ:: home_httpd_vhosts_mysite_2ecom_httpdocs_newsbot_groupkeywords_2epl :: ReadInForm /home/httpd/vhosts/mysite.com/httpdocs/newsbot/groupkeywords.plラインでそれが動作する11

他の回と呼ばれます正しくエラーなし。

奇妙なことは矛盾していることです。私はファイルから1つの出力を得て、数分後にリフレッシュして、もう1つを得ることができます。私はいくつかの "内部サーバーエラー"メッセージと500の応答ヘッダーも実際のコンテンツと一緒に持っています。 &ReadInForm;という行をコメントアウトすると、毎回問題が解決されるので、私はそれを絞り込んだが、何を入れても問題はない。Form.pm。私は空のサブルーチン（上記のように）を置くことさえできますが、それでも問題は解決しません。

これをデバッグする方法についてもわかりません。どのようにそれが矛盾している可能性はありますか？ Perlコンパイラはキャッシュの裏側で何らかの仕組みをしていますか？

Answer 1

あなたのホストは明らかにApache mod_perlを使用しています。 mod_perlを明示的にコーディングする必要があります。ところで、あなたのコードはperl 4とcgi-lib.pl、1996 vintageの匂いがします。とにかくglobal variables are completely forbiddenとyou can't modify @INC under mod_perlとにかく、mod_perlの下であなたのスクリプトは動作しません。 "use strict; use warnings;"をスクリプトに入れ、適切なCGIまたはmod_perlフォームの解析モジュールと関数を使用する方がよいでしょう。

しかし、コードのこのスタイルは動作するはずです。これにより

#!/usr/bin/perl 

# I don't know what this BEGIN block is for, but I suspect it may not work or causes subtle bugs... 
BEGIN { chdir('/home/httpd/vhosts/mysite.com/httpdocs/newsbot'); } 


use strict; 
use warnings; 
use Form; 
use File; 
use Mysite; 

#Read in All Form Variables 
Form::ReadInForm(); 

をフォームに。午後：

use strict; 
use warnings; 

package Form; 

sub ReadInForm { 
}  
1; 

編集：あなたのコードは古いですし、あなたはあなたの大幅な見直しを保存したい場合、あなたはスクリプトコードと変数宣言のすべてを含む「メイン」サブを作成し、簡単に呼び出すことができますそれこの方法：

旧スクリプト：

#!/usr/bin/perl 

# the following line will fail with "undeclared variable" under "use strict" 
$a="test"; 
print "$a\n"; 

新しいスクリプト：

#!/usr/bin/perl 

use strict; 
use warnings; 

# call the main loop enclosing everything else  
main(); 

sub main { 
    # first declare all variables 
    my $a; 

    # then add there all the code: 
    $a="test"; 
    print "$a\n"; 
} 

この方法でスクリプトを「近代化」することができます。

Answer 2

この後、2017年に私の最近の同様の経験に基づいてこのスレッドに追加することが1つあります。 mod_perlで動かすと、古い1990年代の古いperlコードは、（http://www.fifi.org/cgi-bin/man2html/usr/share/man/man3/mod_perl_traps.3pm.gz）で明快に説明されているように、奇妙なエラーを経験するはずです。また、mod_perlはスレッド再利用のためにperlサーバコードを35倍高速化するために作成されていることは他の文書からも明らかですが、この作業をきれいにするためには古いperl CGIのやり方を避けなければなりません。

これは理論的には大変です！しかし、必ずしもそうではありません...

私の1つの注意点は、そこの愛好家のperl_mod guruコミュニティにこれです。レガシperlを実行する方法を決めるときは、mod_perlの使用を自動的に提案しないでください。そして、予期せぬレガシーperlコードの移植担当者に予期せぬコード変更を強制します。

代わりに、レガシーコードを（最大限の効率で再利用可能なスレッド環境で）実行する必要があるかどうか、または昔ながらのシングルスレッドCGIが問題ないかどうかを最初に判断します。

私の場合と同じです。私は1998年にCGI Perlオンライン注文システムを作った。最初のものの1つ。今すぐ（2017年に）私は書いた古いコード（レジュームアイテムのようなもの）を実証するために単にデプロイしたかったのです。それはデモとして以外は実行されません。

mod_perlはOVERKILLですが、私の新しいホスティングサイトのSysAdminsはmod_perlをインストールしなければならないと主張していましたが、それはアドバイスされた共通の習慣でしたが、mod_perlが何をするのか、古いCGI perlシステム。しかし、私はその時にどちらもしなかった。だから、私は彼らが尋ねたときにやったのですが、後でmod_perlの落とし穴を知りました。私はそれらを1つずつ落としました。

私は単純にmod_perlをロードしていないと、サーバのデフォルト設定が古いCGIだったので、これらのエラーは起こりませんでした。

注意書きEmptor。