perlfaq3 - プログラミングツール ($Revision: 1.38 $, $Date: 1999/05/23 16:08:30 $) FAQのこのセクションでは、プログラマーツールやプログラミングサポートに 関する質問に回答しています。 (○○をするにはどうすればいいの?) CPAN(perlfaq2を参照して下さい)はもう見ましたか? あなたの問題を解決してくれるような モジュールを誰かがすでに作っているのを見つけられるかもしれません。 適切なマニュアルページは見ましたか? 簡単なインデックスを挙げておきます: A crude table of contents for the Perl man page set is found in perltoc. 無加工の Perl のマニュアルページセットの目次の一覧がperltocにあります。 (どうすれば対話的にPerlを使えますか?) 典型的なやり方は、perldebug(1)マニュアルページにあるような Perl デバッガを以下の例のように“空の”プログラムに対して使うことです: これで、正しい Perl コードをタイプするだけで即座にそれが評価されます。 同様に、シンボルテーブルの検査やスタックのバックトレースを得ること、 変数の値の確認、ブレークポイントの設定、そしてシンボリックデバッガで 行える典型的な操作が可能です。 (Perlシェルはありますか?) 一般的にはなし、です。(Perl と一緒に配布されている)Shell.pm モジュールは、 Perl が Perl 言語の一部ではないコマンドをシェルコマンドのように 試してみるようにさせます。ソース配布と一緒にある perlsh は単純で、 おもしろみに書けるものかもしれませんが、あなたの要求には十分かもしれません。 (私のPerlプログラムをどうやってデバッグするの?) use warning や -wは使いましたか? これらは怪しいところを警告してくれます。 use strictを試しましたか? これはシンボリックリファレンスを 使えないようにし、あなたが bareword を使ってサブルーチン呼び出しの前に 宣言を行うようにします。 さらに(これが一番重要なことですが)my, our, use varsを使って 宣言するように強制します。 各システムコールの戻り値をチェックしましたか? オペレーティングシステム (そして Perl)はその呼び出しが成功したかを、 そしてそれがなぜなのかをあなたに返しています。 /etc/cantwrite") or die "Couldn't write to /etc/cantwrite: $!\n"; ]]> perltrapを読みましたか? そこには古参の Perl プログラマーと 新参の Perl プログラマーに対する gocha がたくさんあります さらにawk、Cのような別の言語から移ってきた人のための セクションもあります。 perldebugで説明されているPerlデバッガを試しましたか? それによりあなたのプログラムをステップ毎に実行することができ、 あなたの思うように働かなかったのがなぜなのかを 調べることができます。 (わたしのPerlプログラムのプロファイルはどうやってとるのでしょう?) You should get the Devel::DProf module from the standard distribution (or separately on CPAN) and also use Benchmark.pm from the standard distribution. The Benchmark module lets you time specific portions of your code, while Devel::DProf gives detailed breakdowns of where your code spends its time. 標準配付キットにある(CPAN にも分離して置いてあります) Devel::DProf モジュールを入手して、標準配布キットにある Benchmark.pm も使ってみるべきでしょう。 ベンチマークは、あなたのプログラムの特定の部分の所要時間を取るのに対して、 Devel::DProf はあなたのプログラムのどこがどのくらい時間を 消費しているのかの詳細を報告します。 Here's a sample use of Benchmark: 以下は Benchmark の使い方の例です: sub { my @a = @junk; map { s/a/b/ } @a; return @a }, 'for' => sub { my @a = @junk; local $_; for (@a) { s/a/b/ }; return @a }, }); ]]> これは以下のような出力を行います (あるマシン上の例。ハードウェア、オペレーティングシステム、その時点での マシンの使用状況によって結果は変わります): Be aware that a good benchmark is very hard to write. It only tests the data you give it and proves little about the differing complexities of contrasting algorithms. 良いベンチマークを書くのは非常に大変だということに注意してください。 ベンチマークはあなたが与えたデータのみをテストし、複雑なアルゴリズムが 使われたときの複雑さとは異なっているものなのです。 (私のPerlプログラムのクロスリファレンスをとるには?) αリリースのPerlコンパイラー(5.005以前の通常の配布ではありません)とともに 公開されているB::XrefモジュールはPerllプログラムに対する クロスリファレンスの報告を生成するのに使えます。 (Perl用のプリティプリンター(フォーマッター)はどこにあるの?) C に対してindent(1)がやるようなリフォーマットを Perl に対して行うような プログラムはありません。スキャナーとパーザとの間の複雑な フィードバック(このフィードバックは vgrind や emacs プログラムを 混乱させるものです)はこれをほとんど Perl パーザを 作るようなものにしています。 Of course, if you simply follow the guidelines in perlstyle, you shouldn't need to reformat. The habit of formatting your code as you write it will help prevent bugs. Your editor can and should help you with this. The perl-mode or newer cperl-mode for emacs can provide remarkable amounts of help with most (but not all) code, and even less programmable editors can provide significant assistance. Tom swears by the following settings in vi and its clones: もちろん、あなたが perlstyleに従っているのであれば、 リフォーマットする必要はないでしょう。自分のプログラムの書式を 統一しておく習慣はバグ対策になります。 あなたの使っているエディターはソースのフォーマッティングを 助けてくれるかもしれません。 emacs の perl モードやより新しい cperl モードは、 コードのほとんど(が、全部ではありません)に対して驚くほどたくさんの手助けを 提供してくれるでしょうし、そしてそれよりも非力なプログラム可能な エディターでさえも明らかな手助けを提供してくれるかもしれません。 Tomはvi(とそのクローン)で以下のような設定を使っています: Now put that in your .exrc file (replacing the caret characters with control characters) and away you go. In insert mode, ^T is for indenting, ^D is for undenting, and ^O is for blockdenting-- as it were. If you haven't used the last one, you're missing a lot. A more complete example, with comments, can be found at http://www.perl.com/CPAN-local/authors/id/TOMC/scripts/toms.exrc.gz これをあなたの.exrcというファイル(キャレットはコントロールキャラクターで 置き換えます)に書き込めば OK です。挿入モードでは^Tはインデントを行い、 ^Dはアンインデントを、^Oはblockdentをします。 最後のものを使ったことがないのなら、あなたはこれまで大損をしています。 コメント付きの、より完全な例は http://www.perl.com/CPAN-local/authors/id/TOMC/scripts/toms.exrc.gz にあります。 vgrindプログラムを使ってレーザープリンターにきれいなコードを 出力させるのであれば、 http://www.perl.com/CPAN/doc/misc/tips/working.vgrind.entry をスタブとして使うことができますが、その結果は、部分的には、 洗練されたコードではないかもしれません。 The a2ps at http://www.infres.enst.fr/%7Edemaille/a2ps/ does lots of things related to generating nicely printed output of documents. http://www.infres.enst.fr/%7Edemaille/a2ps/ にある a2ps は 奇麗な出力とドキュメントを作るということに関して多くのことを行います。 (Perl用のetags/ctagsはありますか?) There's a simple one at http://www.perl.com/CPAN/authors/id/TOMC/scripts/ptags.gz which may do the trick. And if not, it's easy to hack into what you want. 単純なものが http://www.perl.com/CPAN/authors/id/TOMC/scripts/ptags.gz にあります。なかったとしても、自分の好みにハックすることは 簡単なことです。 (Perlの統合開発環境とかWindows Perl Editorはありますか?) Perl programs are just plain text, so any editor will do. Perl プログラムは単なるテキストなので、どんなエディタでも作成できます。 If you're on Unix, you already have an IDE--Unix itself. The UNIX philosophy is the philosophy of several small tools that each do one thing and do it well. It's like a carpenter's toolbox. あなたが Unix を使っているなら、あなたはすでに統合開発環境を 手にしています--それは Unix 自身です。 Unix の哲学は、一つのことをうまくこなせる小さなツールを複数 組み合わせることです。 これは大工の道具箱に似ています。 If you want a Windows IDE, check the following: Windows の統合開発環境がほしいなら、以下をチェックしてください。 CodeMagicCD http://www.codemagiccd.com/ Komodo ActiveState's cross-platform, multi-language IDE has Perl support, including a regular expression debugger and remote debugging (http://www.ActiveState.com/Products/Komodo/index.html). (Visual Perl, a Visual Studio.NET plug-in is currently (early 2001) in beta (http://www.ActiveState.com/Products/VisualPerl/index.html)). ActiveState のクロスプラットフォーム・多言語 IDE は、 正規表現デバッガ、リモートデバッグを含む Perl サポートがあります (http://www.ActiveState.com/Products/Komodo/index.html)。 (Visual Perl, Visual Studio.NET プラグインは(2001年初頭)現在 ベータ版です(http://www.ActiveState.com/Products/VisualPerl/index.html))。 The Object System (http://www.castlelink.co.uk/object_system/) is a Perl web applications development IDE. (http://www.castlelink.co.uk/object_system/) は Perl web アプリケーション 開発 IDE です。 PerlBuilder (http://www.solutionsoft.com/perl.htm) is an integrated development environment for Windows that supports Perl development. (http://www.solutionsoft.com/perl.htm) は Windows 用統合開発環境で、 Perl の開発にも対応しています。 Perl code magic (http://www.petes-place.com/codemagic.html). visiPerl+ http://helpconsulting.net/visiperl/, from Help Consulting. http://helpconsulting.net/visiperl/, Help Consulting 製です。 For editors: if you're on Unix you probably have vi or a vi clone already, and possibly an emacs too, so you may not need to download anything. In any emacs the cperl-mode (M-x cperl-mode) gives you perhaps the best available Perl editing mode in any editor. エディタ使いへ: あなたが Unix を使っているなら、おそらく vi か vi クローンが すでにあるはずで、emacs もあるかもしれません。 それで、あなたは何もダウンロードする必要はないかもしれません。 あらゆるバージョンの emacs で使える cperl-mode (M-x cperl-mode) は おそらくエディタでの Perl 編集モードの中で最高のものでしょう。 For Windows editors: you can download an Emacs Windows のエディタ使いへ: Emacs がダウンロード可能です。 GNU Emacs http://www.gnu.org/software/emacs/windows/ntemacs.html MicroEMACS http://members.nbci.com/uemacs/ XEmacs http://www.xemacs.org/Download/index.html or a vi clone such as あるいは以下のような vi クローンもあります。 Elvis ftp://ftp.cs.pdx.edu/pub/elvis/ http://www.fh-wedel.de/elvis/ Vile http://vile.cx/ Vim http://www.vim.org/ win32: http://www.cs.vu.nl/%7Etmgil/vi.html For vi lovers in general, Windows or elsewhere: http://www.thomer.com/thomer/vi/vi.html. 一般的な、Windows やその他の vi 愛好者のために: http://www.thomer.com/thomer/vi/vi.html. nvi (http://www.bostic.com/vi/, available from CPAN in src/misc/) is yet another vi clone, unfortunately not available for Windows, but in UNIX platforms you might be interested in trying it out, firstly because strictly speaking it is not a vi clone, it is the real vi, or the new incarnation of it, and secondly because you can embed Perl inside it to use Perl as the scripting language. nvi is not alone in this, though: at least also vim and vile offer an embedded Perl. nvi (http://www.bostic.com/vi/, CPAN の src/misc/ にもあります)は vi クローンの一つで、残念ながら Windows では動作しませんが、 UNIX プラットフォームを使っているなら試してみるべきです。 第一の理由としては、厳密には vi クローンではないものの、 実際は vi、あるいは vi の子孫であるからです。 第二の理由としては、Perl を内蔵していて、Perl をスクリプト言語として 使えるからです。しかし、nvi はこれらの機能をもつ唯一のものではありません。 少なくとも vim と vile も内蔵 Perl を提供しています。 The following are Win32 multilanguage editor/IDESs that support Perl: 以下は Perl をサポートしている Win32 多言語エディタ/IDE です。 Codewright http://www.starbase.com/ MultiEdit http://www.MultiEdit.com/ SlickEdit http://www.slickedit.com/ There is also a toyedit Text widget based editor written in Perl that is distributed with the Tk module on CPAN. The ptkdb (http://world.std.com/~aep/ptkdb/) is a Perl/tk based debugger that acts as a development environment of sorts. Perl Composer (http://perlcomposer.sourceforge.net/vperl.html) is an IDE for Perl/Tk GUI creation. CPAN で Tk モジュールと共に配布されている、Perl で書かれた toyedit Textウィジェットベースのエディタがあります。 ptkdb(http://world.std.com/~aep/ptkdb/) は 開発環境として振舞う Perl/tk ベースのデバッガです。 Perl Composer(http://perlcomposer.sourceforge.net/vperl.html)は Perl/Tk GUI を使った IDE です。 In addition to an editor/IDE you might be interested in a more powerful shell environment for Win32. Your options include エディタ/統合開発環境に加えて、Win32 環境でのより強力な シェル環境に興味があるかもしれません。 選択肢としては以下のものがあります: Bash from the Cygwin package (http://sources.redhat.com/cygwin/) Ksh from the MKS Toolkit (http://www.mks.com/), or the Bourne shell of the U/WIN environment (http://www.research.att.com/sw/tools/uwin/) Tcsh ftp://ftp.astron.com/pub/tcsh/, see also http://www.primate.wisc.edu/software/csh-tcsh-book/ Zsh ftp://ftp.blarg.net/users/amol/zsh/, see also http://www.zsh.org/ MKS and U/WIN are commercial (U/WIN is free for educational and research purposes), Cygwin is covered by the GNU Public License (but that shouldn't matter for Perl use). The Cygwin, MKS, and U/WIN all contain (in addition to the shells) a comprehensive set of standard UNIX toolkit utilities. If you're transferring text files between Unix and Windows using FTP be sure to transfer them in ASCII mode so the ends of lines are appropriately converted. On Mac OS the MacPerl Application comes with a simple 32k text editor that behaves like a rudimentary IDE. In contrast to the MacPerl Application the MPW Perl tool can make use of the MPW Shell itself as an editor (with no 32k limit). BBEdit and BBEdit Lite are text editors for Mac OS that have a Perl sensitivity mode (http://web.barebones.com/). これは Mac OS で動作するテキストエディタで、 Perl 用のモードがあります(http://web.barebones.com/)。 Alpha is an editor, written and extensible in Tcl, that nonetheless has built in support for several popular markup and programming languages including Perl and HTML (http://alpha.olm.net/). これはエディタで、Tcl で書かれており、拡張可能です。 それでもいくつかの有名なマークアップ言語とプログラミング言語 (Perl と HTMLを含みます)への対応を内蔵しています(http://alpha.olm.net/)。 Pepper and Pe are programming language sensitive text editors for Mac OS X and BeOS respectively (http://www.hekkelman.com/). Pepper と Pe はそれぞれ Mac OS X と BeOS 用のプログラミング言語向け テキストエディタです(http://www.hekkelman.com/)。 (vi用のPerlマクロはどこで手に入れられますか?) For a complete version of Tom Christiansen's vi configuration file, see http://www.perl.com/CPAN/authors/Tom_Christiansen/scripts/toms.exrc.gz , the standard benchmark file for vi emulators. The file runs best with nvi, the current version of vi out of Berkeley, which incidentally can be built with an embedded Perl interpreter--see http://www.perl.com/CPAN/src/misc. viエミュレーターの標準ベンチマークファイルである Tom Christiansen の vi コンフィグレーションファイルの完全なものは http://www.perl.com/CPAN/authors/Tom_Christiansen/scripts/toms.exrc.gz を見てください。これはBerkeleyの外にあるviのカレントバージョンである nvi で最もよく実行されます。nvi は組み込みのPerlインタプリタを つけてビルドすることもできます。 http://www.perl.com/CPAN/src/misc を参照してください。 (emacsのperlモードはどこで入手できますか?) Emacs のバージョン 19 パッチレベル 22 から、perl-mode.el と組み込みの Perl デバッガをサポートしています。 これらは標準の Emacs19 配布セットと一緒にあるはずです。 Perlのソースディレクトリには、“emacs”というディレクトリがあって、 そこにはキーワードをカラー表示したり、コンテキストセンシティブな ヘルプなどのご機嫌なことを提供するcperl-modeがあります。 emacsのperl-modeは“main'foo”(シングルクォート)スタイルを扱うもので、 インデントやハイライトをおかしくしてしまうことに注意してください。 いずれにしろ、“main::foo”を使うべきでしょう。 (Perlと一緒にcursesを使うには?) CPANにあるCursesモジュールは、cursesライブラリに対する動的に ロード可能なオブジェクトモジュールインターフェースを提供します。 ちょっとしたデモが http://www.perl.com/CPAN/authors/Tom_Christiansen/scripts/rep; にあります。このプログラムはコマンドを繰り返し、必要に応じて 画面を更新し、topと同じくrep ps axuをレンダリングします。 (どうすればPerlとXやTkを使えますか?) Tkは完全にPerlベースで、Tkを使うためにTclの使用が強制されないような、 Tkツールキットに対するオブジェクト指向インターフェースです。 SxはAthena ウィジェットセットに対するインターフェースです。 これらの両方ともCPANから入手できます。 http://www.perl.com/CPAN/modules/by-category/08_User_Interfaces/ を参照してください。 Perl/Tkに関する貴重な情報として、 Perl/Tkに関するFAQが http://w4.lns.cornell.edu/%7Epvhp/ptk/ptkTOC.html にあります。 また、 http://www.perl.com/CPAN-local/authors/Stephen_O_Lidie/ にはPerl/Tkのリファレンスが、 http://www-users.cs.umn.edu/%7Eamundson/perl/perltk/toc.html にはマニュアルページがあります。 (どうやれば CGIやTkを使わずに単純なメニューを生成できますか?) cursesベースの http://www.perl.com/CPAN/authors/id/SKUNZ/perlmenu.v4.0.tar.gz このモジュールが助けになるかもしれません。 (undumpってなんですか?) See the next question on ``How can I make my Perl program run faster?'' 次の質問を参照してください。 (どうすれば私のPerlプログラムをもっと速くできますか?) その最善の方法とは、よりよいアルゴリズムを使うということです。 ラクダ本の第八章にはあなたが感心をよせるかもしれない幾つかの効率的な tips があります。 Jon Bentleyの著作“Programming Pearls”(ミススペルではありません!) (邦訳「珠玉のプログラミング」)にも最適化に関するいくつかの Tips があります。 ベンチマークとプロファイルによって、 あなたのプログラムのどこに手を入れて最適化するのが正しいのかを はっきりさせ、ちまちまと高速化を行うのではなくより良いアルゴリズムを 探す手掛かりになります。そして、どうしようもなくなったときには いつ新しいハードウェアを買うかということを知る手掛かりともなります。 A different approach is to autoload seldom-used Perl code. See the AutoSplit and AutoLoader modules in the standard distribution for that. Or you could locate the bottleneck and think about writing just that part in C, the way we used to take bottlenecks in C code and write them in assembler. Similar to rewriting in C, modules that have critical sections can be written in C (for instance, the PDL module from CPAN). 別のアプローチには、時々使う Perl コードを オートローディングするというものがあります。 このために標準配布キットにある AutoSplitモジュールと AutoLoader モジュールを参照してください。 あるいは、ボトルネックとなっているところを特定し、 その部分を C で書くことを考えるかもしれません。 ちょうど C で書かれたプログラムのボトルネックをアセンブラで書くのと同じことです。 C で書き直すという意味では、 クリティカルセクションを持ったモジュールを C で書き直すというのも同様です(例えば、CPANにある PDLモジュールがそうです)。 幾つかのケースでは、バイトコードを生成したり(これはコンパイル時間を 節約します)Cへコンパイルするようなバックエンドコンパイラーを使う 価値があるかもしれません。これによってコンパイル時間を節約したり 実行時間が小さく(といってもそれほど多くはない)なるでしょう。 Perl プログラムのコンパイルに関する質問を参照してください。 もしあなたが今、perlの実行ファイルと共有ライブラリlibc.soを リンクしているのであれば、スタティックにlibc.aとリンクしてperlを 再ビルドすることによって、10パーセントから25パーセント性能を 向上させることがほとんどの場合可能です。 これはperlの実行ファイルを大きなものにしてしまいますが、 あなたのPerlプログラム(とプログラマー)はスタティックリンクされたことを 感謝するでしょう。 より詳しい情報は、ソース配布にあるINSTALLというファイルを参照してください。 根拠のないレポートが(入出力重視のアプリケーションで)sfio を使っている Perlインタプリタはそれを使っていないものよりも 高性能であると主張しています。 これを試すには、ソース配布にあるINSTALLというファイルの、 特に “Selecting File I/O mechanisms” というセクションを参照してください。 undump プログラムは、コンパイル済みの形式でディスクに格納することで Perlプログラムを高速化するのに古くは使われていました。 これはほんの一部のアーキテクチャーでのみ働くものであって、 最早価値ある選択肢ではなく、かつ、よい解決策ではありません。 (どうすれば私のPerlプログラムのメモリ消費量を少なくできますか?) 時間と空間とを天秤に掛けたとき、Perlはほとんど常にメモリーに関する 問題を放棄します。PerlにおけるスカラーはCの文字列よりもメモリーを消費し、 配列も同様です。ハッシュは更にメモリを使います。 まだ行うことは残ってはいるものの、最近のリリースではこの問題に対処しています。 たとえば5.004にあるように、重複したハッシュキーは全てのハッシュで共有されます。 このため、(そのハッシュキーの格納のための)再割り付けの必要はありません。 substr()やvec()を使って配列をシミュレートすることで大幅に効率を 上げられることがあるでしょう。 たとえば千個のブール値を持った配列は、 少なくとも二万バイトの空間を必要とします。 しかし、これを125バイトのビットベクターに置き換えることができます-- これで劇的にメモリを節約できます。 標準のTie::SubstrHashモジュールもデータ構造の幾つかの型に対する助けを してくれるでしょう。あなたがデータ構造のスペシャリスト (例えば行列など)モジュールとともに仕事をしようとしているのなら、 Cで実装されたモジュールはPerlで実装された等価なモジュールよりも 少ないメモリしか使わないでしょう。 試してみるべきもう一つの事柄は、あなたの使っているPerlがシステムの mallocを使っているのかPerl組み込みのmallocを使っているのかを知ることです。 いずれを使っているにしろ、別のものを使うようにしてみてそれによる差を確かめます。 mallocに関する情報はソース配布にあるINSTALLというファイルにあります。 perl -V:usemymallocとタイプすればperlが使っている mallocがどちらであるかを知ることができます。 (ローカルなデータへのポインターを返すことは危険ですか?) いいえ。Perlのガーベッジコレクションシステムはそれを気をつけて扱います。 (どうすれば、配列やハッシュを解放して私のプログラムを小さくできますか?) それはできません。ほとんどのシステムでは、プログラムのために 割り付けたメモリーは、決してシステムに返されることはありません。 これは、長期間動作しているプログラムが時々自分自身を 再起動する理由でもあります。 一部のオペレーティングシステム(特にFreeBSD)では、 最早使われていないメモリーの塊をまとめているらしいのですが、 それは(現時点では)Perlには影響を及ぼしません。 MacはOSに返却したメモリーの回収が信用できる (遅いという問題はあるものの) 只一つのプラットフォームのようです。 私たちはIntel用Linux(Redhat 5.1)において、undef $scalarが システムにメモリーを返却するという報告を受けています。一方で Solaris2.6はそのような動作はしないようです。 一般的には自分で試してみるということになるでしょう。 しかしながら、変数に対して賢明なmy()の使用をすることで、 それらの変数がスコープからはずれたときにPerlがそれらが使っていた領域を 解放してプログラムの他の部分で使えるようにする助けになります。 もちろんグローバル変数は決してスコープから外れることはなく、そのため、 undef()やdeleteを使って同様のことができるにもかかわらず、それらの 空間を自動的に取り戻すようなことはできません。 一般的には、メモリ割り付けと解放はあなたが扱えることではなく、 データ型の先行割り付け(preallocation)がうまくいっていたとしても Perlがどうやっているかを心配すべきものです。 (どうやれば私のCGIスクリプトをもっと効率よくできますか?) 普通のPerlプログラムを速くしたり小さくしたりするための基準とは別に、 CGIプログラムには更に別の基準があります。 CGIプログラムは一秒に数回実行される可能性があります。 実行する度毎にスクリプトの再コンパイルとシステムメモリーを 一メガバイト以上割りつけることが必要となります。これは問題点となり得ます。 Cへコンパイルすることは助けにはなりません。 なぜなら、プロセスのスタートアップ時のオーバーヘッドがボトルネックだからです。 このオーバーヘッドを避けるためのポピュラーな手段が二つあります。 解決策の一つはApache HTTPサーバー(http://www.apache.org/から入手可能)に mod_perlかmod_fastcgiのいずれかのプラグインモジュールを 取り込ませて実行させるというものです。 mod_perlとApache::Registry モジュール(mod_perlと一緒に配布されて います)と組み合わせることで、httpdは組み込みのPerl インタプリタと共に実行させるようになります。 これで、あなたのスクリプトは事前にコンパイルされ、 それをfork抜きで同じアドレス空間で実行されるようになります。 Apatche エクステンションはまた、 Perlに内部サーバーAPIをアクセスすることを許可するので、 Perlで記述されたモジュールはCで書かれたモジュールができることはなんでも できるようになります。 mod_perlに関する詳細は http://perl.apache.org/ を参照してください。 FCGIモジュール(CPANにあります)と mod_fastcgiモジュール(http://www.fastcgi.comで入手できます) はあなたのPerlプログラムのそれぞれを永続的 CGI デーモンプロセスにします。 これらの解決策は両方ともあなたの使うシステムで効果がない可能性があり、 また、あなたが書いたCGIプログラムに依存する方法なので、 注意して検査してください。 http://www.perl.com/CPAN/modules/by-category/15_World_Wide_Web_HTML_HTTP_CGI/ を参照してください。 A non-free, commerical product, ``The Velocity Engine for Perl'', (http://www.binevolve.com/ or http://www.binevolve.com/velocigen/ ) might also be worth looking at. It will allow you to increase the performance of your Perl programs, running programs up to 25 times faster than normal CGI Perl when running in persistent Perl mode or 4 to 5 times faster without any modification to your existing CGI programs. Fully functional evaluation copies are available from the web site. フリーソフトではない、商用の製品の``The Velocity Engine for Perl'' があります(http://www.binevolve.com/ または http://www.binevolve.com/velocigen/)。 これがお望みのものかもしれません。 これはまた、あなたのPerlプログラムの性能を引き上げ、 persistent Perlモードで実行されている 通常のCGI Perlの25倍の早さにすることもありますし、 すでにあるCGIプログラムも何も変更せずに四倍から五倍早いものに します。機能が全て使える評価版が先のwebサイトで入手可能です。 (どうやれば私のPerlプログラムのソースを隠せるでしょうか?) 削除しましょう :-) まじめな話、様々な“セキュリティ”レベルを持った 幾つかの解決策があります(ほとんどは満足行くものではないでしょう)。 First of all, however, you can't take away read permission, because the source code has to be readable in order to be compiled and interpreted. (That doesn't mean that a CGI script's source is readable by people on the web, though--only by people with access to the filesystem.) So you have to leave the permissions at the socially friendly 0755 level. しかしながら、まず最初に、あなたは読み取り権限(read permission)を 落とすことはできません。 なぜなら、スクリプトのソースコードはコンパイルとインタープリットのために 読み取り可能でなければならない からです(これはCGIスクリプトのソースコードがweb上で、 読み取り可能であることとは違います-- ファイルシステムに対してアクセスできる人だけが読み取り可能です)。 ですから、権限の設定を少なくとも socially friendly な 0755 の レベルにしておく必要があります。 中にはこれをセキュリティ上の問題であると考えている人もいます。 あなたのプログラムが安全でないことを行った場合、 そして、人々がそのような安全でないことを暴露する方法を知らないことに 頼っているのなら、安全ではないのです。 誰かが、安全でないことを見つけだすこととソースを見ることなしにそれを 暴露することはしばしば可能となるのです。 セキュリティバグを直すのではなくてそのバグを隠すといった、 知られていないことに頼るセキュリティ(security through obscurity)は 小さなセキュリティの傷です。 ソースフィルター(CPANで入手可能なFilter::*)を使った暗号化を試すこともできます。 しかし、悪意在るプログラマーはそれを複号化できるかもしれません。 あなたはバイトコードコンパイラーとインタプリタを (上で説明したように)使うことを試せるかもしれませんが、 探りたがりの人はそれを逆コンパイルできるかもしれません。 (上で説明したような)ネイティブコードコンパイラーを試すこともできますが、 クラッカーはそれを逆アセンブルできるかもしれません。 これらの手段は、あなたのプログラムを手に入れようとする人達に様々な困難を もたらしますが、 誰もそれを決定的に防ぐ障壁にすることはできないのです(Perlのみに 限らず、あらゆる言語で真となります)。 あなたが、誰かがあなたのプログラムを元になにか利益を 得るのではないかということを考えているのなら、 プログラムの最後の行を制限付きライセンスとすれば、 あなたに法的な安全性 (legal security)をもたらすでしょう。 あなたのソフトウェアをライセンスし、 “This is unpublished proprietary software of XYZ Corp. Your access to it does not give you permission to use it blah blah blah.” (本ソフトウェアは、XYZコーポレイションにより作成された非公開の 独占的ソフトウェアです。あなたがこれにアクセスすることは許されていません、 云々)のような文章で味付けします。もちろん私たちは弁護士ではありませんから、 あなたが確実に自分のライセンスが有効なものになるようにしたいのなら、 弁護士に会っておくべきでしょう。 (どうやれば私のPerlプログラムをバイトコードやCへコンパイルできますか?) Malcolm Beattieは多機能バックエンドコンパイラー(multifunction backend compiler)を作成しました。 これはCPANで入手することができ質問の両方ともを行えます。 このコンパイラーはperl5.005のリリースに 含まれていますが、まだまだ実験段階のもので、 あなたがプログラマーであるなら使って遊ぶこともできますが、 プログラマーでない人々が望んでいるものではありません。 Merely compiling into C does not in and of itself guarantee that your code will run very much faster. That's because except for lucky cases where a lot of native type inferencing is possible, the normal Perl run-time system is still present and so your program will take just as long to run and be just as big. Most programs save little more than compilation time, leaving execution no more than 10-30% faster. A few rare programs actually benefit significantly (even running several times faster), but this takes some tweaking of your code. Cコードへの単なる変換はあなたのプログラムをより早く実行するように するものではありません。なぜならそれは、内部型(native type)の インタフェースの数多くがが使用可能であるという幸運な場合を除き、 通常のPerlのランタイムシステムはまだ(プログラムの中に)存在していて、 それによってあなたのプログラムはその大きさに応じた分だけ 起動に時間がかかるからなのです。 ほとんどのプログラムはコンパイル時間程の節約しかできず、 実行時間はせいぜいが10から30%程度でしょう。 ほんの一部のプログラムは目に見えるような改善が得られるでしょう (何倍も早くなることもあります)が あなたのプログラムを少々ひねくり回すことになります。 コンパイラーのカレントバージョンが、オリジナルのPerlの実行ファイルと 同じくらいの大きさのコンパイル済みスクリプトを生成することを 知ってびっくりするかもしれません。 これは、現在のものでは全てのプログラムが全体がeval()文で囲まれているかのように 扱われているからです。 これは、共有ライブラリ libperl.soを作成してそれを使うようにすることで 劇的に小さくすることができます。 詳しくは、Perlのソース配布キットにある INSTALLというpodfileを 参照してください。 あなたの使っている perl バイナリをこのライブラリとリンクすれば、 perlバイナリを取るに足らないくらい小さくします。 たとえば、ある著者のシステムでは、/usr/bin/perl はたったの11kバイトの 大きさでしかないのです! In general, the compiler will do nothing to make a Perl program smaller, faster, more portable, or more secure. In fact, it can make your situation worse. The executable will be bigger, your VM system may take longer to load the whole thing, the binary is fragile and hard to fix, and compilation never stopped software piracy in the form of crackers, viruses, or bootleggers. The real advantage of the compiler is merely packaging, and once you see the size of what it makes (well, unless you use a shared libperl.so), you'll probably want a complete Perl install anyway. 一般的にいって、コンパイラーはPerlプログラムを小さくもしませんし、 早くもしなければ、移植性を増すこともせず、安全にもしません。 実際、状況がより悪くなることもあります。 実行ファイルは大きくなり、あなたの使うVMシステムは全体をロードするのに より時間を要すようになりますし、バイナリコードは壊れやすくて 修整しにくいものです。 そして、コンパイルはソフトウェアの不法使用者のクラッキングも、ウィルスも、 密売も防ぐことはできません。 コンパイラーの本当の有利な点は、単にパッケージングということで、 出来上がった実行ファイルの大きさ(まあ、libperl.so共有ライブラリを 使った場合は別ですが)を見てしまえば、Perl全体をインストールしてしまおうと 思うかもしれません。 (どうやればPerlをJavaにコンパイルできますか?) You can also integrate Java and Perl with the Perl Resource Kit from O'Reilly and Associates. See http://www.oreilly.com/catalog/prkunix/ . オライリーの Perl リソースキットを使って Java と Perl を統合することも出来ます。 http://www.oreilly.com/catalog/prkunix/ を参照してください。 Perl 5.6 comes with Java Perl Lingo, or JPL. JPL, still in development, allows Perl code to be called from Java. See jpl/README in the Perl source tree. Perl 5.6 は Java Perl Lingo(JPL) と協調できます。 JPL はまだ開発中ですが、Perl コードを Java から呼び出せます。 Perl ソースツリーの jpl/README を参照してください。 (MS-DOS, NT, etc で '#!perl'が動作するようにするには?) OS/2では (*.cmdファイルの先頭をこのようにするだけです(-Sは、 cmd.exeの`extproc'に関するバグのためです)。DOSの場合は、適切なバ ッチファイルを作ってALTERNATIVE_SHEBANG を行うべきでしょう(詳 細は、ソース配布キットにあるINSTALLというファイルを参照してくだ さい)。 The Win95/NT installation, when using the ActiveState port of Perl, will modify the Registry to associate the .pl extension with the perl interpreter. If you install another port, perhaps even building your own Win95/NT Perl from the standard sources by using a Windows port of gcc (e.g., with cygwin or mingw32), then you'll have to modify the Registry yourself. In addition to associating .pl with the interpreter, NT people can use: SET PATHEXT=%PATHEXT%;.PL to let them run the program install-linux.pl merely by typing install-linux. Windows 95やWindows NTで ActiveStateの移植したPerl を使うのなら、これは.plという拡張子をperlインタプリタに関連 づけるようにレジストリを変更します。その他の移植になるperl を使うか、あるいはあなた自身が Windowsに移植されたgcc(cygwinやmingw)を 使って標準ソースからPerlをビルドするというの であれば自分自身でレジストリを変更する必要があるでしょう。 .plとインタプリタを関連づけることによって、NTを使っている 人はinstall-linux.pl を install-linuxのように起動することが 可能です。NTではSET PATHEXT=%PATHEXT%;.PLのようにします。 Macintosh Perl programs will have the appropriate Creator and Type, so that double-clicking them will invoke the Perl application. Macintosh Perlのプログラムは適切なCreatorとTypeとを持っているで しょうから、ダブルクリックするだけでPerlアプリケーシ ョンが起動するでしょう。 重要!:あなたが何をするにしても、どうか不満を感じないでください。 そして、あなたのプログラムがwebサーバのために動作するようにさせ るためにperlインタプリタをcgi-binディレクトリに放り込むよう なことはしないでください。これは非常に大きなセキュリティ上の リスクとなります。正しく動作させるための方法を考えるための時間を 取ってください。 (コマンドライン上で便利なperlプログラムを書けますか?) できます。詳しくはperlrunを読んでください。幾つかのサンプルを 以下に挙げておきます(ここでは標準のUNIX シェル引用規則に従っていると 仮定します)。 そう、最後のは Obfuscated Perl コンテストにエントリーされてましたね :-) (なぜ私の DOS/Mac/VMSシステムでは一行野郎(one-liners)は動かないのでしょうか?) この問題は、そういったシステムのコマンドインタプリタが、 一行野郎が作られた環境であるUNIXのシェルの引用規則とは異なるこということです。 一部のシステムでは、シングルクォートをダブルクォートに 変更する必要があるかもしれません(これはUNIXやPlan9といったシステムでは してはいけません)。 同様に、%を%%に変更する必要もあるかもしれません。 例を挙げましょう: 問題は、これらの例の中に信頼できるものがないということです: コマンドインタープリタに依存します。 UNIXでは、最初の二つはほとんどの場合動作するでしょう。 DOSでは、どれも働かないかもしれません。 4DOSをコマンドシェルとしているのなら、以下のようにするのがよいと思います: "Hello world\n"" ]]> Macでは、あなたが使っている環境に依存します。 MacPerlシェルやMPWは、制御キャラクターのようなMacの非ASCIIキャラクターが 自由に使えるという点を除いて、 UNIXシェルのように数種類の引用規則をサポートします。 ダブルクォート(")、シングルクォート(')、バッククォート(`)の 代わりにqq(), q(), qx()をそれぞれ使います。これによって 一行野郎を書くことが簡単になるかもしれません。 There is no general solution to all of this. It is a mess, pure and simple. Sucks to be away from Unix, huh? :-) この件全てに関する一般的な解決策はありません。ごちゃごちゃで、 純粋で、単純です。Unix から離れたくなくなったでしょう? :-) [この回答の一部はKenneth Albanowskiから寄せられました] (わたしがPerlによるCGIやWebプログラミングについて学べる場所は?) モジュールなら、CPANからCGIモジュールやLWPモジュールを入手しましょう。 教科書なら、本にあるweb stuffの特に決定的な二つを参照しましょう。 “Why do I get 500 Errors” (なんで 500 Errors になるの) “Why doesn't it run from the browser right when it runs fine on the command line” (なぜコマンドラインからだとちゃんと動くのに、ブラウザーからだと だめなんでしょうか)のようにwebに関連する問題や疑問は以下のソースを 参照してください。 (オブジェクト指向のPerlプログラミングはどこで学べますか?) A good place to start is perltoot, and you can use perlobj, perlboot, and perlbot for reference. Perltoot didn't come out until the 5.004 release; you can get a copy (in pod, html, or postscript) from http://www.perl.com/CPAN/doc/FMTEYEWTK/ . 始めるにはよい場所は perltootです。リファレンスとしてperlobj, perlboot, <perlbot>が使えます。 perltoot はリリース5.004までは添付されていませんでした。 そのコピーを http://www.perl.com/CPAN/doc/FMTEYEWTK/ から入手することが可能です。 (C と Perl のリンクについてはどこで学べますか? [h2xs, xsubpp]) もしPerlからCを呼び出したいのなら、perlxstutから始めてperlxs, xsubpp, perlgutsへと進みます。CからPerlを呼び出したいのなら、 perlembed, perlcall, perlgutsを読みましょう。 すでにあるエクステンションの作者がどのようにそれを記述し、 どのように彼らの問題を解決したのかを見ることで多くのことが 学べるのだということを忘れないでください。 (perlembedやperlgutsなんかを読んだのだけど、 私のCプログラムにperlを組み込めません。 何が悪いのでしょうか?) CPANからExtUtils::Embedキットをダウンロードして、`make test'を 実行してください。 もしこのテストに合格したのなら、podを何度も何度もくり返しくり返し 読んでください。 テストに失敗したなら、perlbugを読んで、perl -Vの出力と make test TEST_VERBOSE=1の出力を添付してバグレポートを送ってください。 (私のスクリプトを実行したとき、こんなメッセージを受け取りました。 これって何を意味しているのでしょうか?) A complete list of Perl's error messages and warnings with explanatory text can be found in perldiag. You can also use the splain program (distributed with Perl) to explain the error messages: perl のすべてのエラーメッセージ、警告メッセージの説明テキスト付きのリストが perldiag にあります。 エラーメッセージを説明するために、 splain プログラムを使うこともできます(これは Perl と一緒に配布されています)。 diag.out splain [-v] [-p] diag.out ]]> あるいは、メッセージを説明的にするようにプログラムを変更します。 or あるいはこう (MakeMakerってなんですか?) このモジュール(標準Perl配布キットの一部です)はMakefile.PLから エクステンションモジュール用のMakefileを作成するために デザインされたものです。 詳しくは ExtUtils::MakeMaker を参照してください。 Copyright (c) 1997-1999 Tom Christiansen and Nathan Torkington. All rights reserved. When included as an integrated part of the Standard Distribution of Perl or of its documentation (printed or otherwise), this works is covered under Perl's Artistic License. For separate distributions of all or part of this FAQ outside of that, see perlfaq. Irrespective of its distribution, all code examples here are in the public domain. You are permitted and encouraged to use this code and any derivatives thereof in your own programs for fun or for profit as you see fit. A simple comment in the code giving credit to the FAQ would be courteous but is not required. Translate: 吉村 寿人 <JAE00534@niftyserve.or.jp> Update: Kentaro Shirakata <argrath@ub32.org> License: GPL or Artistic