ここでは、Windows ユーザー向けの説明を行っている。UNIX系 の場合、ホームディレクトリの中に入れれば良いだけの話なので。lib/ を作って、その中に入れても良いけど…。
サブルーチン(ライブラリ)のセットアップ…と言っても、基本的にはただ @INC パスのどこかに、そのファイルを置いておくだけだ。つまり、どこに置けば良いか…それだけの話ではある。が、この話題を突き詰めていくと、Perl をどこにインストールすれば良いか という話にまで遡って考える必要に迫られる(特に Windows ではね)。本稿も、そこから始めるとしよう。
目次を見て、「おいおい、遠回りしすぎだろ」…と思った人もいるかもしれない。筆者も同感だ。でもね、自作スクリプトを公開してみようと考えているなら、労力を軽減できる環境を構築しないと、継続していくのが大変になってしまうんだよね。そう、最初が肝心ってわけ。
筆者は、その辺りを重視して、敢えて回りくどい説明を試みることにした。こんな説明をするのは、筆者自身も非常に面倒だと感じているので、気力が萎える前に、ざっくり説明するにとどめたい。稚拙な文章になると思うが、大目に見てほしい。
題名のとおり。以上。…これでは、さすがに乱暴すぎるね。はっきり言うと、Windows で自家サーバを公開しては駄目だよ…ってこと。詳細は省くが、セキュリティ上の理由と、Windows のライセンス違反に抵触する可能性があるためだ。
Windows パソコンしか持っていない人は、加入プロバイダの Web サーバを公開サーバとして利用する…それが一番簡単だ。おそらく、プロバイダの Web サーバは『Apache』のはずだ。当文書も、それを想定し、執筆している。
我ながら、分かりにくい題名だと思う。申し訳ない。当文書で言う CGI 用の言語 とは、もちろん Perl を指している。プロバイダの Web サーバが『Apache』ならば、Perl も必ずインストールされている…そう考えて構わないはず。『mod_perl』モジュールだけでも Apache は動作可能だが、それは特殊な環境だ。ruby, php 等を CGI 言語に採用しているケースがそれに該当する。
自作スクリプトを公開したいなら、必然的に Web ページを作って、そこから情報発信することになるはず。でも、Web ページ自身は自宅のパソコンで作成することになる。Web ページが完成したら、それがちゃんと機能するかを確認してからアップロードすべきだろう。その動作チェックを行うために必要なのがローカルサーバ(非公開サーバ)だ。ローカルサーバは非公開なので、Windows に設置しても構わないことになっている。
ローカルサーバは、Web サーバの環境を可能な限り模倣するのが原則となる。親和性とは、そういう意味だ。特に CGI スクリプトは、Web、ローカルの双方の環境で正常に動作することが求められる。
そのためには、当然ながら Web、ローカルの双方に Perl が導入されていなければならない。そして、Web サーバが Apache であるならば、ローカルサーバにも Apache を導入する。それは、ごく自然な発想と言えるだろう。が、それこそが Windows ユーザーがつまづく最初の関門となっている。次項以降で、その関門を安直に回避する方法を説明する。
UNIX系(Linux等) と Windows では、実行ファイルのインストール先が異なっている。もちろん、Perl のインストール先も然りだ。通常、Perl をデフォルト設定でインストールすると、『Perl の実行パス』は次のとおりとなる。
UNIX ： /usr/local/bin/perl
Linux ： /usr/bin/perl
Windows： C:/Perl/bin/perl.exe ← ※ ActivePerl の場合
UNIX系での実行ファイルのインストール先は、基本的には…
1. /usr/local/bin
2. /usr/bin
のどちらかに決められていて、それ以外の場所にユーザーが勝手にインストール先を変える事は許されないルールになっている。この制限によって、ディレクトリ単位でのセキュリティレベルの設定が有効に働く仕組みになっているのだ。1. と 2. の違いは、
1. /usr/local/bin
標準システムには含まれていないアプリケーションを、システムの導入
後に追加する場合のインストール先(オプション的な扱い)。
2. /usr/bin
システムにとって『標準実装』のアプリケーションを導入する場所。基
本的に、この場所にある実行ファイルは、 OS のインストール時に一緒
にインストールされる(プレ・インストール)。
UNIX と Linux で、Perl の実行パスが異なるのは『時代背景の差』に起因するものだ。Linux において、Perl は『標準システム』の一員として、地位が昇格したってわけ。そもそも、カーネルから末端のアプリケーションに至るまで、全ソフトが GNU (または GPL) ライセンス(いわゆるフリーソフト)で統一されている Linux ディストリビューションにおいては、Perl が標準実装されていても、何の不思議もない。
一方の Windows の場合、実行ファイルのインストール先は『管理者ユーザー』ならば、ある程度は自由に変更することができる。これは、Apache をローカルサーバとして導入する時、重要な意味を持ってくる。Apache は、CGI スクリプトのシュバング行を参照する。シュバング行とは、CGI スクリプトの先頭に必ず記述される…
#!/usr/local/bin/perl
…という行のことだ。これは Perl の実行パスを表している。仮に、Windows での Perl の実行パスがデフォルトの『C:/Perl/bin/perl.exe』になっていて、ローカルサーバが Apache だとすれば、ローカルサーバで動作する CGI スクリプトのシュバング行は…
#!C:/Perl/bin/perl
…と記述しなければならない(.exe は省略可能)。カレントドライブが C: に決まっているのなら、ドライブレターは省略できる。つまり…
#!/Perl/bin/perl
…と、記述できる。しかし、このシュバング行は UNIX系では有り得ない記述なので、ローカルサーバに置いた CGI スクリプトを Web 上にアップロードするには、その直前にシュバング行を毎回修正してからアップロードする必要が生じる。これは非常に面倒で、その処理を自動化したとしても効率が悪いのは否めない。
この問題を安直に解決するなら、Windows版 Perl の実行パスを、UNIX系システムと同じにすれば良い。前述のとおり、UNIX系では『実行ファイルのインストール先を勝手に変更することはできない』ので、代わりに Windows のインストール先を変更してやる…そういうわけ。
Windows 対応版の Perl ディストリビューションは幾つか存在するが、通常は Active State 社(カナダ)が開発している ActivePerl を使うのが定番となっている。ActivePerl は、Windows API との親和性が強化されたディストリビューションだ。もちろん、フリーソフトとして無料でダウンロードできる。
ActivePerl のアーカイブは、通常は .msi 実行形式をダウンロードする。このアーカイブをダブルクリックすればインストールが始まる。しばらくするとデフォルトの『インストールパス』が表示されるので、ここで Web サーバと同じ(ような)パスを指定する。次のように指定する。
こうすることで、Windows(ローカルサーバ)で動作する CGIスクリプトを、シュバング行を変更することなく UNIX系(Webサーバ)でもそのまま使うことが可能になる。
さて。Perl のインストール・パスが決まれば、おのずと @INC パスも限定されてくる。今までコツコツと説明してきたが、筆者の気力は既に萎え始めている。論理が一気に飛躍するが、次項で結論を書いてしまおう。
とりあえず、ActivePerl をデフォルトでインストールしていたユーザーは、まずはアンインストールし、前述のパスで再インストールすることを薦める。これから書く結論は、その前提で説明する。
Perl では、サブルーチン(外部関数)やメソッド、モジュールは、use や require 関数を使って読み込む。これらの関数は特殊配列の @INC の内容を参照する。『INC』は『インクルード』の略と思われる。コマンドラインで『perl -V』を実行すると、@INC の内容を知ることが出来る。前述の【ケース1】と【ケース2】(ActivePerl の場合)では、それぞれ次のとおりとなる。
サブルーチンやモジュールは、UNIX系では『〜〜/lib』というディレクトリに置くのが慣例になっている。ActivePerl もその慣例に倣っている。さらに、上記の 2種類のパスには、次のような意味がある。
〜/lib → Perl, ActivePerl『標準ライブラリ』の置き場所
〜/site/lib → その他の 『汎用ライブラリ』の置き場所
※ つまり、lib とは『ライブラリ』の略だ。
というわけで、foussin分室で公開しているサブルーチンは、『〜/site/lib』にコピー(または移動)しておけば良い。
が、話はまだ、ここでは終わらない。『〜/site/lib』にコピーして良いのは完動品に限る…ということだ。仮に、あなたが自作のサブルーチンを作っているとすれば、他人が作ったスクリプトと一緒に『〜/site/lib』に放り込むより、自作スクリプト専用のフォルダを用意して、その中に入れておいた方が編集・管理がしやすいだろう。問題は、その場所をどこにするか、だ。
自作スクリプトをどこに置くか…。残念ながら、foussin 自身も『これしかない!』という定番設定には辿り着いていない。なので、今から紹介するのは『当面の措置』として foussin が推奨する仮設定に過ぎない。予めご了解ください。
C:/usr/
|
+-- apache/ Apache2.2 のインストール場所
+-- bat/ 自作 バッチファイル(コマンド)の置き場所
+-- bin/ 自作 Perl スクリプト(コマンド)の置き場所
+-- lib/ 自作 Perl スクリプト(サブルーチン)の置き場所
|
+-- local/ Perl のインストール場所
|
+-- bin/ Perl の実行ファイルの置き場所
+-- eg/
+-- etc/
+-- html/
+-- lib/ Perl 標準ライブラリの置き場所
+-- man/
+-- site/
|
+-- lib/ 汎用ライブラリの置き場所
C:/usr/ Perl のインストール場所
|
+-- bin/ Perl の実行ファイルの置き場所
+-- eg/
+-- etc/
+-- html/
+-- lib/ Perl 標準ライブラリの置き場所
|
+-- local/ ローカルサーバ専用
| |
| +-- apache/ Apache2.2 のインストール場所
| +-- bat/ 自作 バッチファイル(コマンド)の置き場所
| +-- bin/ 自作 Perl スクリプト(コマンド)の置き場所
| +-- lib/ 自作 Perl スクリプト(サブルーチン)の置き場所
|
+-- man/
+-- site/
|
+-- lib/ 汎用ライブラリの置き場所
上記の赤字部分に自作のサブルーチンを置くが、このままでは、まだ不便なので、次のようにする。
【ケース1】の場合 … 『C:/usr/lib』と入力。
【ケース2】の場合 … 『C:/usr/local/lib』と入力。
7. 『OK』を押して窓を閉じる。この設定は Windows Vista の場合で説明しているが、XP や 7 でもさほどの違いはないはず。この設定を行うことによって、@INC パスの先頭にこれらのパスが追加される。『perl -V』を実行すれば、新たにパスが追加されたことが確認できる(下記)。
%ENV:
PERL5LIB="C:/usr/lib"
@INC:
C:/usr/lib
C:/usr/local/site/lib
C:/usr/local/lib
.
『サブルーチンのセットアップ』についての説明は、以上でおしまいとする。力尽きた…。