ここでは、PerlスクリプトをブラウザとLinuxサーバに接続したssh(Secure Shell)対応ターミナルエミュレータ(TTSSH/TeraTerm SSH、PuTTY等)から実行・デバッグ・エラーチェックをしてみましょう。
ssh接続に関しては、サーバがsshに対応している必要があります。
LANではなくインターネットを介してssh接続を利用しない、利用できない場合、セキュリティ面からサーバにアクセスして作業することは避けるべきです。
また、サーバがレンタルで、特に共有サーバの場合には、サーバ負荷を考慮して一度に接続できるssh接続数やrdb接続数、ftp接続数を限定して設定しているのが一般的でレンタルサーバによっては途中で強制終了されたり、なかなか接続できなかったりといった状況も起こり得ます。
こうした状況では、サーバも、自分もストレスがたまることもあり、不健康ですからサーバアクセスは必要最小限に抑え、ローカル実行環境で開発、テストを行い、サーバ上には完成版をアップロードするのが賢明です。
ローカルPCのOSがUNIX/Linux、Mac OS X、UNIX代替環境などの場合は、たいていPerlはプリインストールされていると思いますが、何らかの理由でこれらOSに追加インストールが必要な場合、またはWindowsの場合にはいくつかの方法でローカルに実行環境を作ることもできます。
例えばWindowsの場合、別途PC Linuxを用意する方法、Windowsマシンのパーティーションを仕切り直してWindowsとLinuxを共存させる方法、また、VM/Virtual Machine/仮想マシンによる仮想環境を使ってLinuxのisoイメージで利用したり、CDから起動できるLive CD、USBメモリにインストールできるLinuxディストリビューションもあったりするのでそれを利用する方法などがあります。
他にも各種OS上で動作するPerl実行環境を備えた『Active Perl』などのディストリビューションを利用する方法でMS-DOSプロンプト・コマンドプロンプトからPerlスクリプトを実行できます。
更にもうひとつは、Windows上で動作する『Cygwin』や『minGW』を利用する方法で、Windows上で(Perlにとどまらない)UNIX/Linuxに近いローカルでの実行環境(やコンパイル環境)を利用することができます。
CygwinやminGW、UNIX/Linuxの基本的な操作についてはUNIX/Linux コマンドやシェル参照。
Windows上でHTTPサーバやデータベース環境もローカルに構築したい場合には、Perl(Active PerlまたはCygwin Perl)の他、ApacheやAn httpdなどのWebサーバ、PostgreSQLやMySQLを個別にインストールして設定することもできます。
An httpd、Postgresqlへのこだわりが特になければXAMPP(Linux用のLAMPPに由来、Win/Mac/Linuxで使えるということから)クロス環境を意味するX、Apache、MySQL、PHP、Perl、更にFTP転送可能な簡易軽量DBであるSQLiteがワンセットになったパッケージを利用すればパッケージのインストールのみでより簡単に構築できたりもします。
Windowsローカル環境でActivePerlをインストールしている場合にはコマンドプロンプト、Cygwinならデフォルトのコマンドプロンプトを流用したものやTTSSH(TeraTerm SSH)付属のcygterm、やっぱりLinuxサーバ環境でやってみたいよ!という場合には、セキュアな接続(ssh)が利用できるTTSSHやPuTTYなどのターミナルエミュレータをゲットしてサーバ情報を設定後、接続してログインします。
念のためPerlがインストールされているかどうかを調べるには
$ perl -v
$ perl -V
($はプロンプト)などとしてバージョン表示を確認するか、UNIX/Linux/Cygwin等代替環境なら
$ which perl
$ which -a perl
$ whereis perl
などとして実行ファイルパスが存在するかどうかを確認してみるのもよいでしょう。
Windowsに代替環境ではなく何らかのPerlディストリビューションをインストールした場合には、先に確認したPerlの実行ファイルパスを環境変数PATHにセットする必要があるでしょう。
UNIX/Linux/Cygwin等代替環境では実行ファイルを格納すべきディレクトリが決まっていて、それらディレクトリパスは既に通っており、それ以外のディレクトリにインストールしない限りは、プリインストール/追加インストールしたかに関わらずパスは通っているはずなので通常は考える必要のない不要な作業です。
ちなみにインストールされていてパスが通っていない場合には、以降の例などでも先に調べたPerlの実行ファイルパスをフルパスで指定する必要があります。
さて、ログイン・接続後、パスさえ通っていれば、下記を実行すれば
$ perl -e 'print "foo\n";'
foo
$
のようにfooが出力されると思いますし、スクリプトを実行するだけならスクリプトのあるディレクトリで
$ perl ファイル名
$ ./ファイル名
$ ファイル名
のいずれかで実行できます。
2つめ、3つめの方法ではスクリプトファイル作成後、UNIX/Linux/代替環境ならchmodで実行パーミッションを立てる必要があり、更に3つめに関しては環境変数PATHにカレントディレクトリとして[.](ドット・ピリオド)がセットされている必要がありますが、この3つめの方法は一般にいくつかの点から推奨されませんから既定ではありません。
理由としては、どのディレクトリ下での実行においてもパス探索を要するのでCPUやメモリなどマシン負荷が懸念される点や[perl]などのインタプリタや[./]を伴う場合に比べ、履歴や補完機能など含め、うっかりミスによる不要な実行の可能性が高くなるなどが挙げられます。
前述の通り、perlのパスが通っていない場合にはperl実行ファイルをフルパス指定すれば、また当該スクリプトファイルがないディレクトリでスクリプトを実行する場合にはファイルをディレクトリ(フォルダ)を含めたフルパスで指定すれば実行できます。
ここでは主にスクリプトについて書きますが、先に触れたfooの出力のようにワンライナーなら
$ perl -e 'print "Hello World!\n"'
などとすれば実行でき、この[e]オプションは、sedのワンライナーの(単独では省略可、複数命令がある場合は必須の)[e]オプションと同じように後に続くシングルクォートで括られた文字列をPerl構文として処理し実行する指示、つまりワンライナーで実行する際の指定です。
実行時に[Can't modify constant item in scalar assignment]といったエラーが出る場合には、そこに表示されているスクリプトファイルのLine(行)や示される文字付近、前後、関数内で必要な行終端を示す[ ; ]や[ ' ]、[ " ]シングルまたはダブルクォーテーションがない、スカラー変数の[ $ ]、配列変数の[ @ ]、ハッシュ[ % ]などがない、逆に認識不能な文字列があるといったようなエラーです。
$ perl -wc bar $ perl -wc foo/bar |
※実行すると[ typo ]という文字が含まれた警告・注意が出力される事がありますが、これは変数などが「宣言なしで現れる」、「ファイル内で1度しか使われてない」という意味あいであり、ファイル分割していて他で宣言している場合にも出力されますのでその場合は無視します。
デバッグする際には、[ perl -d ファイル名 ]とデバッグオプションでEnter、前述の-wcと組み合わせて[ perl -dwc ファイル名 ]とすれば、デバッグと同時に警告と注意も出力してくれます。
$ perl -d bar
$ perl -d foo/bar
$ perl -dwc bar
$ perl -dwc foo/bar
などとします。
コンソールでのPerlデバッグモード(perl5DB.pl)の場合には、dbxやgdbに近い操作性でブレークポイントを行指定[c 28](例:28行目)、ステップ実行[s](step)、または、[n](next)、実行[ r ]、デバッグの初期化[R]などを入力してEnterキーを押します。
もちろん他にもモードがありますのでperldocやヘルプファイルを参照して下さい。
ちなみにスクリプトの1行めのインタプリタ指定行でオプションを渡すことができるので(当然、公開ディレクトリではやらない方がよいですが)ブラウザ上でエラーを確認することもできます。
というわけで[ #!/usr/local/bin/perl ](や[ #!/usr/bin/perl ]※利用サーバの正しいパス)に実行オプション[ w ]や[ c ]または両方[ wc ]を指定して
#!/usr/local/bin/perl -c #!/usr/local/bin/perl -w #!/usr/local/bin/perl -wc |
などとします。
そして.plまたは.cgiファイルを保存してURL入力欄からフルパスで指定するか、ダミーでよいのでhtmlファイルにアンカーを設定して呼び出します(get)。
但し、この手法ではスクリプトの状態によっては期待するエラー状態を見られない場合もあります。
その場合には、[ strict.pm ]や[ warnnig.pm ]というプラグマモジュール、または[ Strict.pm ]や[ Warnnig.pm ]という拡張モジュールを[ use ]を使って
use strict; use warnnig; |
や
use Strict; use Warnnig; |
としてモジュールを取り込むとエラー出力してくれますが、perl5にはプラグマはあると思いますが、それ以前のperl、サーバのperlの標準インストールではこれらのモジュールがない場合もありますので、その場合にはモジュールを入手する必要があります。
因みに[ strict.pm ]や[ Strict.pm ]は、Perlの文法規則を「厳密にチェック」するモジュールですので変数宣言を省略できるPerlでも変数宣言が必要となったりします。
○ Encode.pm または Unicode.pm ×↑jcode.pl または Jcode.pm↑ |
○ CGI.pm ×↑cgi-lib.pl |
DBI.pm/DBD.pm |
DBI.pmは、Perlにおける標準データベースインタフェースモジュールでDBD.pmがDBIのドライバとなり、併用することでOracle、PostgreSQL、MySQL等で共通利用できる優れものモジュールです。
DBI.pmについては既に情報も多いと思いますので詳細は割愛するつもりですが、んんん?と少し悩まされるかもしれない点について1つだけ。
DBI.pmを利用していてスクリプトが通っていて(他に何ら影響がなくて)も[ Issuing rollback() for database handle being DESTROY'd without explicit disconnect() ... ]といった注意・警告がブラウザ上に表示される場合があります。
これは、{ AutoCommit => 0 }にしている場合に起こります。
[ INSERT ][ UPDATE ][ DELETE ]だけでなく、『[ SELECT ]にも[ commit ][ rollback ]が必要』という内容です。
SQLとしては本来なら[ SELECT ]には[ commit ][ rollback ]は不要なので注意・警告は不要じゃん!と言わずに(不必要なはずなのに)全ての[ SELECT ]に丁寧に[ commit ][ rollback ]を入れてあげると、これらの注意、警告は表示されなくなります。
DBI.pmを利用しない場合はもちろん、AutoCommitをオンにしておけば起こらないと思われますが、現行のDBI.pmを利用する場合で、[ SELECT ]した後、[ fetch ]したレコードや個々のバインドデータを利用してそのまま一連の流れで処理を継続して[ INSERT ][ UPDATE ][ DELETE ]・・・といったケースも多いはずなのでAutoCommitをオフにせざるを得ないケースも多々あるでしょう。
Carpを利用して警告を出さないというアイデアも見かけたことがありますが、使い方を間違えたのかCarpも使える管理人の環境では回避できず警告出力されたままだったので、管理人はDBIを利用する場合には[ SELECT ]に丁寧に[ commit ][ rollback ]を入れるようにしています。