perlfaq-5.0150043

Other versions:
perlfaq-5.021010
perlfaq-5.021009
perlfaq-5.0150044
perlfaq-5.0150042
perlfaq-5.0150039
5.14.1
5.12.1
5.10.1
5.10.0
5.8.4
5.6.1

編集

変更履歴

誤訳の報告

原文を表示/隠す

名前
説明
AUTHOR AND COPYRIGHT

名前¶

perlfaq3 - Programming Tools

perlfaq3 - プログラミングツール

説明¶

This section of the FAQ answers questions related to programmer tools and programming support.

FAQ のこのセクションでは、プログラマーツールやプログラミングサポートに関する質問に回答しています。

○○をするにはどうすればいいの?¶

Have you looked at CPAN (see perlfaq2)? The chances are that someone has already written a module that can solve your problem. Have you read the appropriate manpages? Here's a brief index:

CPAN (perlfaq2 を参照して下さい)はもう見ましたか? あなたの問題を解決してくれるようなモジュールを誰かがすでに作っているのを見つけられるかもしれません。適切なマニュアルページは見ましたか? 簡単なインデックスを挙げておきます:

Basics

(基礎)

perldata - Perl data types
perlvar - Perl pre-defined variables
perlsyn - Perl syntax
perlop - Perl operators and precedence
perlsub - Perl subroutines

Execution

(実行)

perlrun - how to execute the Perl interpreter
perldebug - Perl debugging

Functions

(実行)

perlfunc - Perl builtin functions

Objects

(オブジェクト)

perlref - Perl references and nested data structures
perlmod - Perl modules (packages and symbol tables)
perlobj - Perl objects
perltie - how to hide an object class in a simple variable

Data Structures

(データ構造)

perlref - Perl references and nested data structures
perllol - Manipulating arrays of arrays in Perl
perldsc - Perl Data Structures Cookbook

Modules

(モジュール)

perlmod - Perl modules (packages and symbol tables)
perlmodlib - constructing new Perl modules and finding existing ones

Regexes

(正規表現)

perlre - Perl regular expressions
perlfunc - Perl builtin functions>
perlop - Perl operators and precedence
perllocale - Perl locale handling (internationalization and localization)

Moving to perl5

(perl5 への移行)

perltrap - Perl traps for the unwary
perl

Linking with C

(Cとのリンク)

perlxstut - Tutorial for writing XSUBs
perlxs - XS language reference manual
perlcall - Perl calling conventions from C
perlguts - Introduction to the Perl API
perlembed - how to embed perl in your C program

Various

(その他)

http://www.cpan.org/misc/olddoc/FMTEYEWTK.tgz (not a man-page but still useful, a collection of various essays on Perl techniques)

http://www.cpan.org/misc/olddoc/FMTEYEWTK.tgz (man ページではありませんが有用な、Perl のテクニックに関するコラム集です)

A crude table of contents for the Perl manpage set is found in perltoc.

無加工の Perl のマニュアルページセットの目次の一覧が perltoc にあります。

対話的に Perl を使うには?¶

The typical approach uses the Perl debugger, described in the perldebug(1) manpage, on an "empty" program, like this:

典型的なやり方は、perldebug(1) マニュアルページにあるような Perl デバッガを以下の例のように「空の」プログラムに対して使うことです:

    perl -de 42

Now just type in any legal Perl code, and it will be immediately evaluated. You can also examine the symbol table, get stack backtraces, check variable values, set breakpoints, and other operations typically found in symbolic debuggers.

これで、正しい Perl コードをタイプするだけで即座にそれが評価されます。同様に、シンボルテーブルの検査やスタックのバックトレースを得ること、変数の値の確認、ブレークポイントの設定、そしてシンボリックデバッガで行える典型的な操作が可能です。

You can also use Devel::REPL which is an interactive shell for Perl, commonly known as a REPL - Read, Evaluate, Print, Loop. It provides various handy features.

Perl のための対話的シェルである Devel::REPL も使えます; これは一般的に REPL (Read, Evaluate, Print, Loop) として知られます。これは様々な便利機能を提供します。

自分のシステムに入っているモジュールを知るには?¶

From the command line, you can use the cpan command's -l switch:

コマンドラインからは、-l オプション付きの cpan コマンドが使えます:

    $ cpan -l

You can also use cpan's -a switch to create an autobundle file that CPAN.pm understands and can use to re-install every module:

また、cpan の -a オプションを使うことで、CPAN.pm が理解して、全てのモジュールを再インストールするために使える autobundle ファイルも作れます。

    $ cpan -a

Inside a Perl program, you can use the ExtUtils::Installed module to show all installed distributions, although it can take awhile to do its magic. The standard library which comes with Perl just shows up as "Perl" (although you can get those with Module::CoreList).

Perl プログラム内では、 ExtUtils::Installed モジュールを使うことで全てのインストールされたディストリビューションを知ることが出来ますが、この魔法を使うには少し時間がかかります。 Perl と共に入る標準ライブラリは単に "Perl" として表示されます (しかしこれらのリストは Module::CoreList で得ることが出来ます)。

    use ExtUtils::Installed;

    my $inst    = ExtUtils::Installed->new();
    my @modules = $inst->modules();

If you want a list of all of the Perl module filenames, you can use File::Find::Rule:

全ての Perl モジュールファイル名の一覧を知りたいなら、 File::Find::Rule が利用できます:

    use File::Find::Rule;

    my @files = File::Find::Rule->
        extras({follow => 1})->
        file()->
        name( '*.pm' )->
        in( @INC )
        ;

If you do not have that module, you can do the same thing with File::Find which is part of the standard library:

このモジュールがない場合、標準ライブラリの一部である File::Find を使って同じことが出来ます:

    use File::Find;
    my @files;

    find(
        {
        wanted => sub {
            push @files, $File::Find::fullname
            if -f $File::Find::fullname && /\.pm$/
        },
        follow => 1,
        follow_skip => 2,
        },
        @INC
    );

    print join "\n", @files;

If you simply need to check quickly to see if a module is available, you can check for its documentation. If you can read the documentation the module is most likely installed. If you cannot read the documentation, the module might not have any (in rare cases):

単にあるモジュールが使えるかどうかを知りたいだけなら、ドキュメントをチェックするという方法があります。もしそのモジュールに関するドキュメントが読めるなら、そのモジュールはきっとインストールされています。ドキュメントが読めない場合、(まれに)モジュールにドキュメントがないという可能性もあります:

    $ perldoc Module::Name

You can also try to include the module in a one-liner to see if perl finds it:

一行野郎でモジュールを読み込めるか試すという手もあります:

    $ perl -MModule::Name -e1

(If you don't receive a "Can't locate ... in @INC" error message, then Perl found the module name you asked for.)

("Can't locate ... in @INC" というエラーがでなければ、Perl が指定されたモジュールを見つけたということです。)

私の Perl プログラムをデバッグするには?¶

(contributed by brian d foy)

(brian d foy によって寄贈されました)

Before you do anything else, you can help yourself by ensuring that you let Perl tell you about problem areas in your code. By turning on warnings and strictures, you can head off many problems before they get too big. You can find out more about these in strict and warnings.

他の事をする前に、あなたのコードの問題を Perl に調べさせることであなたへの助けとすることが出来ます。警告と厳密性をオンにすることによって、多くの問題を大事になる前に阻止できます。これらに関する詳細は strict と warnings にあります。

    #!/usr/bin/perl
    use strict;
    use warnings;

Beyond that, the simplest debugger is the print function. Use it to look at values as you run your program:

その他に、もっとも単純なデバッガは print 関数です。プログラム実行中に値を見るために使います:

    print STDERR "The value is [$value]\n";

The Data::Dumper module can pretty-print Perl data structures:

Data::Dumper モジュールは Perl のデータ構造をきれいに表示します:

    use Data::Dumper qw( Dumper );
    print STDERR "The hash is " . Dumper( \%hash ) . "\n";

Perl comes with an interactive debugger, which you can start with the -d switch. It's fully explained in perldebug.

Perl には対話的デバッガが同梱されていて、-d スイッチを付けることで起動できます。 perldebug で完全に説明されています。

If you'd like a graphical user interface and you have Tk, you can use ptkdb. It's on CPAN and available for free.

もし GUI がほしくて、Tk がある場合、ptkdb が使えます。これは CPAN にあり、自由に使えます。

If you need something much more sophisticated and controllable, Leon Brocard's Devel::ebug (which you can call with the -D switch as -Debug) gives you the programmatic hooks into everything you need to write your own (without too much pain and suffering).

もっと洗練されていて制御可能なものが必要なら、Leon Brocard の Devel::ebug (-D オプションを使って -Debug として呼び出せます)を使うと、なんでもあなたが自分で書いたものを使って(それほどの苦痛なしに)プログラム上のフックを作れます。

You can also use a commercial debugger such as Affrus (Mac OS X), Komodo from Activestate (Windows and Mac OS X), or EPIC (most platforms).

Affrus (Mac OS X), Activestate Komodo (Windows と Mac OS X), EPIC (ほとんどのプラットフォーム) といった商用デバッガも使えます。

私の Perl プログラムのプロファイルを取るには?¶

(contributed by brian d foy, updated Fri Jul 25 12:22:26 PDT 2008)

(brian d foy によって寄贈され、Fri Jul 25 12:22:26 PDT 2008 に更新されました)

The Devel namespace has several modules which you can use to profile your Perl programs.

Devel 名前空間には Perl プログラムをプロファイルするために使えるいくつかのモジュールがあります。

The Devel::NYTProf (New York Times Profiler) does both statement and subroutine profiling. It's available from CPAN and you also invoke it with the -d switch:

Devel::NYTProf (New York Times Profiler) は文とサブルーチンの両方のプロファイリングを行います。これは CPAN から入手可能で、やはり -d オプションで起動できます:

    perl -d:NYTProf some_perl.pl

It creates a database of the profile information that you can turn into reports. The nytprofhtml command turns the data into an HTML report similar to the Devel::Cover report:

レポートに変換できるプロファイル情報のデータベースを作成します。 nytprofhtml コマンドで、データを Devel::Cover レポートと似たような HTML レポートに変換します:

    nytprofhtml

You might also be interested in using the Benchmark to measure and compare code snippets.

また、コード片を計測、比較するために Benchmark を使うことにも興味があるかもしれません。

You can read more about profiling in Programming Perl, chapter 20, or Mastering Perl, chapter 5.

プロファイルに関するさらなることについては Programming Perl の 20 章か Mastering Perl の 5 章を読んでください。

perldebguts documents creating a custom debugger if you need to create a special sort of profiler. brian d foy describes the process in The Perl Journal, "Creating a Perl Debugger", http://www.ddj.com/184404522 , and "Profiling in Perl" http://www.ddj.com/184404580 .

perldebguts には、特別な種類のプロファイラが必要な場合にカスタムデバッガを作る方法が書かれています。 brian d foy は The Perl Journal の "Creating a Perl Debugger", http://www.ddj.com/184404522 と "Profiling in Perl" http://www.ddj.com/184404580 で処理を記述しています。

Perl.com has two interesting articles on profiling: "Profiling Perl", by Simon Cozens, http://www.perl.com/lpt/a/850 and "Debugging and Profiling mod_perl Applications", by Frank Wiles, http://www.perl.com/pub/a/2006/02/09/debug_mod_perl.html .

Perl.com にはプロファイリングに関する二つの興味深い記事があります: Simon Cozens による "Profiling Perl" http://www.perl.com/lpt/a/850 と Frank Wiles による "Debugging and Profiling mod_perl Applications" http://www.perl.com/pub/a/2006/02/09/debug_mod_perl.html です。

Randal L. Schwartz writes about profiling in "Speeding up Your Perl Programs" for Unix Review, http://www.stonehenge.com/merlyn/UnixReview/col49.html , and "Profiling in Template Toolkit via Overriding" for Linux Magazine, http://www.stonehenge.com/merlyn/LinuxMag/col75.html .

Randal L. Schwartz はプロファイリングについて Unix Review の "Speeding up Your Perl Programs" http://www.stonehenge.com/merlyn/UnixReview/col49.html と、 Linux Magazine の "Profiling in Template Toolkit via Overriding" http://www.stonehenge.com/merlyn/LinuxMag/col75.html で書いています。

私の Perl プログラムのクロスリファレンスをとるには?¶

The B::Xref module can be used to generate cross-reference reports for Perl programs.

B::Xref モジュールが Perl プログラムに対するクロスリファレンスの報告を生成するのに使えます。

    perl -MO=Xref[,OPTIONS] scriptname.plx

Perl 用のプリティプリンター(フォーマッター)はありますか?¶

Perl::Tidy comes with a perl script perltidy which indents and reformats Perl scripts to make them easier to read by trying to follow the rules of the perlstyle. If you write Perl, or spend much time reading Perl, you will probably find it useful.

perl スクリプト perltidy に同梱されている Perl::Tidy は Perl スクリプトを perlstyle のルールに従って読みやすくしようとします。 Perl を書いたとき、あるいは多くの時間を 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 Christiansen and many other VI users swear by the following settings in vi and its clones:

もちろん、あなたが perlstyle に従っているのであれば、リフォーマットする必要はないでしょう。自分のプログラムの書式を統一しておく習慣はバグ対策になります。あなたの使っているエディターはソースのフォーマッティングを助けてくれるかもしれません。 emacs の perl モードやより新しい cperl モードは、コードのほとんど(が、全部ではありません)に対して驚くほどたくさんの手助けを提供してくれるでしょうし、そしてそれよりも非力なプログラム可能なエディターでさえも明らかな手助けを提供してくれるかもしれません。 Tom Christiansen とその他の多くの vi 使いは vi (とそのクローン)で以下のような設定を使っています:

    set ai sw=4
    map! ^O {^M}^[O^T

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. A more complete example, with comments, can be found at http://www.cpan.org/authors/id/TOMC/scripts/toms.exrc.gz

これをあなたの .exrc というファイル(キャレット文字はコントロール文字で置き換えます)に書き込めば OK です。挿入モードでは ^T はインデントを行い、^D はアンインデントを、 ^Oは blockdent をします。コメント付きの、より完全な例は http://www.cpan.org/authors/id/TOMC/scripts/toms.exrc.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 an IDE, check the following (in alphabetical order, not order of preference):

統合開発環境がほしいなら、以下をチェックしてください (アルファベット順であって、有用な順ではありません):

Eclipse

http://e-p-i-c.sf.net/

The Eclipse Perl Integration Project integrates Perl editing/debugging with Eclipse.

The Eclipse Perl Integration Project は Perl の編集/デバッグを Eclipse に統合します。

Enginsite

http://www.enginsite.com/

Perl Editor by EngInSite is a complete integrated development environment (IDE) for creating, testing, and debugging Perl scripts; the tool runs on Windows 9x/NT/2000/XP or later.

EngInSite の Perl Editor Perl スクリプトを作成・テスト・デバッグするための完全な統合開発環境(IDE)です; ツールは Windows 9x/NT/2000/XP 移行で動作します。

Kephra

http://kephra.sf.net

GUI Editor written in Perl using wxWidgets and Scintilla with lots of smaller features. Aims for an UI based on Perls principles like TIMTWTDI and "easy things should be ..".

wxWidgets と Scintilla を使って Perl で書かれ、多くのより小さい機能を持つ GUI エディタです。 UI のための狙いは、TIMTWTDI や "easy thinks should be .." のような Perl の原則に基づいています。

Komodo

http://www.ActiveState.com/Products/Komodo/

ActiveState's cross-platform (as of October 2004, that's Windows, Linux, and Solaris), multi-language IDE has Perl support, including a regular expression debugger and remote debugging.

ActiveState のクロスプラットフォーム(2004 年 10 月現在 Windows, Linux, Solaris) 多言語 IDE は、正規表現デバッガ、リモートデバッグを含む Perl サポートがあります。

Notepad++

http://notepad-plus.sourceforge.net/

Open Perl IDE

http://open-perl-ide.sourceforge.net/

Open Perl IDE is an integrated development environment for writing and debugging Perl scripts with ActiveState's ActivePerl distribution under Windows 95/98/NT/2000.

Open Perl IDE は Windows 95/98/NT/2000 で動作する ActiveState の ActivePerl で Perl スクリプトを書いたりデバッグしたりするための統合開発環境です。

OptiPerl

http://www.optiperl.com/

OptiPerl is a Windows IDE with simulated CGI environment, including debugger and syntax-highlighting editor.

OptiPerl は擬似 CGI 環境を持つ Windows 用 IDE で、デバッガと文法によって色付けされるエディタを含みます。

Padre

http://padre.perlide.org/

Padre is cross-platform IDE for Perl written in Perl using wxWidgets to provide a native look and feel. It's open source under the Artistic License. It is one of the newer Perl IDEs.

Padre は、ネイティブな見た目を提供するために wxWidgets を使って Perl で書かれた Perl のためのクロスプラットフォーム IDE です。これは the Artistic License によるオープンソースです。これは新しい Perl IDE の一つです。

PerlBuilder

http://www.solutionsoft.com/perl.htm

PerlBuilder is an integrated development environment for Windows that supports Perl development.

PerlBuilder は Windows 用統合開発環境で、Perl の開発にも対応しています。

visiPerl+

http://helpconsulting.net/visiperl/index.html

From Help Consulting, for Windows.

Help Consulting 製で、Windows 用です。

Visual Perl

http://www.activestate.com/Products/Visual_Perl/

Visual Perl is a Visual Studio.NET plug-in from ActiveState.

Visual Perl は ActiveState 製で、Visual Studio.NET へのプラグインです。

Zeus

http://www.zeusedit.com/lookmain.html

Zeus for Windows is another Win32 multi-language editor/IDE that comes with support for Perl.

Zeus for Windows は Perl にも対応した、もう一つの Win32 複数言語エディタ/IDEです。

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 編集モードの中で最高のものでしょう。

If you are using Windows, you can use any editor that lets you work with plain text, such as NotePad or WordPad. Word processors, such as Microsoft Word or WordPerfect, typically do not work since they insert all sorts of behind-the-scenes information, although some allow you to save files as "Text Only". You can also download text editors designed specifically for programming, such as Textpad ( http://www.textpad.com/ ) and UltraEdit ( http://www.ultraedit.com/ ), among others.

Windows を使っているのなら、NotePad や WordPad といったプレーンテキストを扱えるエディタを使うことが出来ます。 Microsoft Word や WordPerfect といったワードプロセッサは一般的には使えません; なぜなら色々な「裏方の」情報を追加するからです; ただし、"Text Only" としてファイルをセーブできるものもあります。また、Textpad ( http://www.textpad.com/ ) や UltraEdit ( http://www.ultraedit.com/ ) といったプログラミングに特化したテキストエディタをダウンロードすることもできます。

If you are using MacOS, the same concerns apply. MacPerl (for Classic environments) comes with a simple editor. Popular external editors are BBEdit ( http://www.barebones.com/products/bbedit/ ) or Alpha ( http://www.his.com/~jguyer/Alpha/Alpha8.html ). MacOS X users can use Unix editors as well.

MacOS を使っているなら、同様の考え方が適用されます。 (Classic 環境用の)MacPerl にはシンプルなエディタが付いています。有名な外部エディタとしては BBEdit ( http://www.barebones.com/products/bbedit/ ) や Alpha ( http://www.his.com/~jguyer/Alpha/Alpha8.html ) があります。 MacOS X ユーザーは Unix エディタも使えます。

GNU Emacs: http://www.gnu.org/software/emacs/windows/ntemacs.html
MicroEMACS: http://www.microemacs.de/
XEmacs: http://www.xemacs.org/Download/index.html
Jed: http://space.mit.edu/~davis/jed/

or a vi clone such as

あるいは以下のような vi クローンもあります:

Vim: http://www.vim.org/
Vile: http://dickey.his.com/vile/vile.html

The following are Win32 multilanguage editor/IDEs that support Perl:

以下は Perl をサポートしている Win32 多言語エディタ/IDE です。

Codewright: http://www.borland.com/codewright/
MultiEdit: http://www.MultiEdit.com/
SlickEdit: http://www.slickedit.com/
ConTEXT: http://www.contexteditor.org/

There is also a toyedit Text widget based editor written in Perl that is distributed with the Tk module on CPAN. The ptkdb ( http://ptkdb.sourceforge.net/ ) is a Perl/Tk-based debugger that acts as a development environment of sorts. Perl Composer ( http://perlcomposer.sourceforge.net/ ) is an IDE for Perl/Tk GUI creation.

CPAN で Tk モジュールと共に配布されている、Perl で書かれた toyedit Text ウィジェットベースのエディタがあります。 ptkdb( http://ptkdb.sourceforge.net/ ) は開発環境として振舞う Perl/Tk ベースのデバッガです。 Perl Composer ( http://perlcomposer.sourceforge.net/ )は 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/ )

Cygwin パッケージ ( http://sources.redhat.com/cygwin/ ) から。
Ksh: from the MKS Toolkit ( http://www.mkssoftware.com/ ), or the Bourne shell of the U/WIN environment ( http://www.research.att.com/sw/tools/uwin/ )

MKS ツールキット ( http://www.mkssoftware.com/ )か、 U/WIN 環境 ( http://www.research.att.com/sw/tools/uwin/ ) の Bourne shell から。
Tcsh: ftp://ftp.astron.com/pub/tcsh/ , see also http://www.primate.wisc.edu/software/csh-tcsh-book/

ftp://ftp.astron.com/pub/tcsh/、 http://www.primate.wisc.edu/software/csh-tcsh-book/ も参照してください。
Zsh: 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 General 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.

MKS とU/WIN は商用(U/WIN は教育・研究目的には無料)で、 Cygwin は GNU General Public License で配布されています (しかしこれは Perl の使用には関係ないはずです)。 Cygwin, MSK, U/WIN は全て(シェルに加えて)広範囲な標準 Unix ツールキットを含んでいます。

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.

Unix と Windows の間でテキストファイルを FTP で転送する場合、改行コードを適切に変更するために ASCII モードにしてください。

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).

Mac OS では MacPerl Application は基本的な IDE のように振舞うシンプルな 32k テキストエディタがついています。 MacPerl Application と対照的に、MPW Perl tool は MPW Shell 自身を (32k の制限なしに)エディタとして使えます。

Affrus: is a full Perl development environment with full debugger support ( http://www.latenightsw.com ).

は、完全なデバッガサポート付きの完全な Perl 開発環境です ( http://www.latenightsw.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://www.his.com/~jguyer/Alpha/Alpha8.html ).

これはエディタで、Tcl で書かれており、拡張可能です; それでもいくつかの有名なマークアップ言語とプログラミング言語 ( Perl と HTML を含みます)への対応を内蔵しています ( http://www.his.com/~jguyer/Alpha/Alpha8.html )。
BBEdit and TextWrangler: are text editors for Mac OS that have a Perl sensitivity mode ( http://www.barebones.com/ ).

これは Mac OS で動作するテキストエディタで、 Perl 用のモードがあります( http://www.barebones.com/ )。

vi 用の Perl マクロはどこで入手できますか?¶

For a complete version of Tom Christiansen's vi configuration file, see http://www.cpan.org/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.cpan.org/src/misc/ .

Tom Christiansen の vi コンフィグレーションファイルの完全なものは vi エミュレータの標準ベンチマークファイルである http://www.cpan.org/authors/Tom_Christiansen/scripts/toms.exrc.gz を参照してください。これは Berkeley の外にあるviのカレントバージョンである nvi で最もうまく実行されます; nvi は組み込みの Perl インタプリタをつけてビルドすることもできます--http://www.cpan.org/src/misc/ を参照してください。

emacs の perl-mode や cperl-mode はどこで入手できますか?¶

Since Emacs version 19 patchlevel 22 or so, there have been both a perl-mode.el and support for the Perl debugger built in. These should come with the standard Emacs 19 distribution.

Emacs のバージョン 19 パッチレベル 22 から、perl-mode.el と組み込みの Perl デバッガをサポートしています。これらは標準の Emacs19 配布セットと一緒にあるはずです。

Note that the perl-mode of emacs will have fits with "main'foo" (single quote), and mess up the indentation and highlighting. You are probably using "main::foo" in new Perl code anyway, so this shouldn't be an issue.

emacs の perl-mode は "main'foo"(シングルクォート)スタイルを扱うもので、インデントやハイライトをおかしくしてしまうことに注意してください。いずれにしろ、"main::foo"を使うべきでしょう。

For CPerlMode, see http://www.emacswiki.org/cgi-bin/wiki/CPerlMode

CPerlMode については、http://www.emacswiki.org/cgi-bin/wiki/CPerlMode を参照してください。

Perl で curses を使うには?¶

The Curses module from CPAN provides a dynamically loadable object module interface to a curses library. A small demo can be found at the directory http://www.cpan.org/authors/Tom_Christiansen/scripts/rep.gz ; this program repeats a command and updates the screen as needed, rendering rep ps axu similar to top.

CPAN にある Curses モジュールは、curses ライブラリに対する動的にロード可能なオブジェクトモジュールインターフェースを提供します。ちょっとしたデモが http://www.cpan.org/authors/Tom_Christiansen/scripts/rep.gz にあります; このプログラムはコマンドを繰り返し、必要に応じて画面を更新し、top と同じく rep ps axu をレンダリングします。

Perl で GUI (X, Tk, Gtk など) を書くには?¶

(contributed by Ben Morrow)

(Ben Morrow によって寄贈されました)

There are a number of modules which let you write GUIs in Perl. Most GUI toolkits have a perl interface: an incomplete list follows.

Perl で GUI を書くための多くのモジュールがあります。ほとんどの GUI ツールキットには perl インターフェースがあります: 以下に不完全なリストを示します。

Tk: This works under Unix and Windows, and the current version doesn't look half as bad under Windows as it used to. Some of the gui elements still don't 'feel' quite right, though. The interface is very natural and 'perlish', making it easy to use in small scripts that just need a simple gui. It hasn't been updated in a while.

これは Unix と Windows で動作し、現在のバージョンは Windows でも以前のように悪くはないです。しかし、GUI 要素には完全に正しい「感じ」ではないものもあります。インターフェースはとても自然で「perl っぽい」もので、単純な GUI がほしいだけの小さいスクリプトで簡単に使えます。これはしばらくの間更新されていません。
Wx: This is a Perl binding for the cross-platform wxWidgets toolkit ( http://www.wxwidgets.org ). It works under Unix, Win32 and Mac OS X, using native widgets (Gtk under Unix). The interface follows the C++ interface closely, but the documentation is a little sparse for someone who doesn't know the library, mostly just referring you to the C++ documentation.

これはクロスプラットフォーム wxWidgets ツールキット ( http://www.wxwidgets.org ) の Perl バインディングです。これはネイティブなウィジェット(Unix では Gtk) を使って、 Unix, Win32, Mac OS X で動作します。インターフェースは C++ インターフェースに近いですが、ドキュメントはライブラリを知らない人にとっては少々手薄なので、たいていは単に C++ ドキュメントを参照することになるでしょう。
Gtk and Gtk2: These are Perl bindings for the Gtk toolkit ( http://www.gtk.org ). The interface changed significantly between versions 1 and 2 so they have separate Perl modules. It runs under Unix, Win32 and Mac OS X (currently it requires an X server on Mac OS, but a 'native' port is underway), and the widgets look the same on every platform: i.e., they don't match the native widgets. As with Wx, the Perl bindings follow the C API closely, and the documentation requires you to read the C documentation to understand it.

Gtk ツールキット ( http://www.gtk.org ) の Perl バインディングがあります。バージョン 1 と 2 でインターフェースが大きく変わったので、個別の Perl モジュールになっています。これは Unix, Win32, Mac OS X で動作し(現在のところ Mac OS X では X サーバーが必要ですが、「ネイティブ」ポートも進行中です)、ウィジェットはどのプラットフォームでも同じような見た目になります(つまり、ネイティブのウィジェットとは一致しません)。 Wx と同様、Perl バインディングは C API に似ていて、これを理解するためには C のドキュメントを読む必要があります。
Win32::GUI: This provides access to most of the Win32 GUI widgets from Perl. Obviously, it only runs under Win32, and uses native widgets. The Perl interface doesn't really follow the C interface: it's been made more Perlish, and the documentation is pretty good. More advanced stuff may require familiarity with the C Win32 APIs, or reference to MSDN.

これは Perl から Win32 GUI ウィジェットのほとんどへのアクセスを提供します。明らかに、これは Win32 でのみ動作し、ネイティブなウィジェットを使います。 Perl のインターフェースは C のインターフェースに本当に従ってはいません: これはより Perl っぽく、ドキュメントもかなりよく出来ています。より高度な機能を使うためには C Win32 API に親しんでいるか、MSDN を参照する必要があります。
CamelBones: CamelBones ( http://camelbones.sourceforge.net ) is a Perl interface to Mac OS X's Cocoa GUI toolkit, and as such can be used to produce native GUIs on Mac OS X. It's not on CPAN, as it requires frameworks that CPAN.pm doesn't know how to install, but installation is via the standard OSX package installer. The Perl API is, again, very close to the ObjC API it's wrapping, and the documentation just tells you how to translate from one to the other.

CamelBones ( http://camelbones.sourceforge.net ) は Mac OS X の Cocoa GUI への Perl のインターフェースで、Mac OS X でのネイティブな GUI の生成に使えます。これは CPAN.pm がどのようにインストールすればよいか知らないフレームワークを必要とするので CPAN にはありませんが、標準 OSX パッケージインストーラ経由でインストールします。再び、Perl API はそれがラッピングしている ObjC API ととても近いので、ドキュメントは単にお互いをどう変換すればいいかについて書いています。
Qt: There is a Perl interface to TrollTech's Qt toolkit, but it does not appear to be maintained.

TrollTech の Qt toolkit への Perl インターフェースはありますが、保守されていないようです。
Athena: Sx is an interface to the Athena widget set which comes with X, but again it appears not to be much used nowadays.

Sx は X に同梱されている Athena ウィジェットセットへのインターフェースですが、やはり最近ではほとんど使われていないようです。

私の Perl プログラムをもっと速くするには?¶

The best way to do this is to come up with a better algorithm. This can often make a dramatic difference. Jon Bentley's book Programming Pearls (that's not a misspelling!) has some good tips on optimization, too. Advice on benchmarking boils down to: benchmark and profile to make sure you're optimizing the right part, look for better algorithms instead of microtuning your code, and when all else fails consider just buying faster hardware. You will probably want to read the answer to the earlier question "How do I profile my Perl programs?" if you haven't done so already.

その最善の方法とは、よりよいアルゴリズムを使うということです。これはしばしば劇的な違いを生みます。 Jon Bentleyの著作 "Programming Pearls" (ミススペルではありません!) (邦訳「珠玉のプログラミング」)にも最適化に関するいくつかの Tips があります。ベンチマークに関するアドバイスは以下のようなものです: ベンチマークとプロファイルによって、あなたのプログラムのどこに手を入れて最適化するのが正しいのかをはっきりさせ、ちまちまと高速化を行うのではなくより良いアルゴリズムを探す手掛かりになります; そして、どうしようもなくなったときにはいつ新しいハードウェアを買うかということを知る手掛かりともなります。まだ読んでいないなら、前述した "How do I profile my Perl programs?" という質問の答えも読みたいと思うでしょう。

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 モジュールがそうです)。

If you're currently linking your perl executable to a shared libc.so, you can often gain a 10-25% performance benefit by rebuilding it to link with a static libc.a instead. This will make a bigger perl executable, but your Perl programs (and programmers) may thank you for it. See the INSTALL file in the source distribution for more information.

もしあなたが今、perl の実行ファイルと共有ライブラリ libc.so をリンクしているのであれば、スタティックに libc.a とリンクして perl を再ビルドすることによって、しばしば 10-25% 性能を向上させることが可能です。これは perl の実行ファイルを大きなものにしてしまいますが、あなたの Perl プログラム(とプログラマー)はスタティックリンクされたことを感謝するでしょう。より詳しい情報は、ソース配布にある INSTALL というファイルを参照してください。

The undump program was an ancient attempt to speed up Perl program by storing the already-compiled form to disk. This is no longer a viable option, as it only worked on a few architectures, and wasn't a good solution anyway.

undump プログラムは、コンパイル済みの形式でディスクに格納することで Perlプログラムを高速化するのに古くは使われていました。これはほんの一部のアーキテクチャーでのみ働くものであって、最早価値ある選択肢ではなく、かつ、よい解決策ではありません。

私の Perl プログラムのメモリ消費量を少なくするには?¶

When it comes to time-space tradeoffs, Perl nearly always prefers to throw memory at a problem. Scalars in Perl use more memory than strings in C, arrays take more than that, and hashes use even more. While there's still a lot to be done, recent releases have been addressing these issues. For example, as of 5.004, duplicate hash keys are shared amongst all hashes using them, so require no reallocation.

時間と空間とを天秤に掛けたとき、Perl はほとんど常にメモリに関する問題を放棄します。 Perl におけるスカラーは C の文字列よりもメモリを消費し、配列も同様です; ハッシュは更にメモリを使います。まだ行うことは残ってはいるものの、最近のリリースではこの問題に対処しています。たとえば 5.004 にあるように、重複したハッシュキーは全てのハッシュで共有されます; このため、(そのハッシュキーの格納のための)再割り付けの必要はありません。

In some cases, using substr() or vec() to simulate arrays can be highly beneficial. For example, an array of a thousand booleans will take at least 20,000 bytes of space, but it can be turned into one 125-byte bit vector--a considerable memory savings. The standard Tie::SubstrHash module can also help for certain types of data structure. If you're working with specialist data structures (matrices, for instance) modules that implement these in C may use less memory than equivalent Perl modules.

substr() や vec() を使って配列をシミュレートすることで大幅に効率を上げられることがあるでしょう。たとえば 1000 個のブール値を持った配列は、少なくとも 20000 バイトの空間を必要とします; しかし、これを 125 バイトのビットベクターに置き換えることができます--これで劇的にメモリを節約できます。標準の Tie::SubstrHash モジュールもデータ構造の幾つかの型に対する助けをしてくれるでしょう。あなたがデータ構造のスペシャリスト(例えば行列など)モジュールとともに仕事をしようとしているのなら、 C で実装されたモジュールは Perl で実装された等価なモジュールよりも少ないメモリしか使わないでしょう。

Another thing to try is learning whether your Perl was compiled with the system malloc or with Perl's builtin malloc. Whichever one it is, try using the other one and see whether this makes a difference. Information about malloc is in the INSTALL file in the source distribution. You can find out whether you are using perl's malloc by typing perl -V:usemymalloc.

試してみるべきもう一つの事柄は、あなたの使っている Perl がシステムの malloc を使っているのか Perl 組み込みの malloc を使っているのかを知ることです。いずれを使っているにしろ、別のものを使うようにしてみてそれによる差を確かめます。 malloc に関する情報はソース配布にある INSTALL というファイルにあります。 perl -V:usemymalloc とタイプすれば perl が使っている malloc がどちらであるかを知ることができます。

Of course, the best way to save memory is to not do anything to waste it in the first place. Good programming practices can go a long way toward this:

もちろん、メモリを節約する一番の方法はまず無駄なことをしないことです。よいプログラミングプラクティスは以下のようなものを通じて得られています。

Don't slurp!

(ファイル全体を読み込まない!)

Don't read an entire file into memory if you can process it line by line. Or more concretely, use a loop like this:

ファイルを行単位で処理するときにファイル全体をメモリに読み込んではいけません。より具体的には、以下のようなループを使います:

    #
    # Good Idea
    #
    while (my $line = <$file_handle>) {
       # ...
    }

instead of this:

以下のような方式はよくないです:

    #
    # Bad Idea
    #
    my @data = <$file_handle>;
    foreach (@data) {
        # ...
    }

When the files you're processing are small, it doesn't much matter which way you do it, but it makes a huge difference when they start getting larger.

処理するファイルサイズが小さいなら、どちらの方法をとっても大きな違いはありません; しかし、ファイルが大きくなるにつれてその差は大きいものとなります。

Use map and grep selectively

(map と grep をうまく選んで使う)

Remember that both map and grep expect a LIST argument, so doing this:

map と grep はどちらも LIST 引数を取るので、以下のようにすると:

        @wanted = grep {/pattern/} <$file_handle>;

will cause the entire file to be slurped. For large files, it's better to loop:

ファイル全体を読み込むことになります。大きなファイルでは以下のようにループしたほうがよいです:

        while (<$file_handle>) {
                push(@wanted, $_) if /pattern/;
        }

Avoid unnecessary quotes and stringification

(不必要なクォートと文字列化を避ける)

Don't quote large strings unless absolutely necessary:

本当に必要でないかぎりは大きな文字列をクォートしてはいけません。

        my $copy = "$large_string";

makes 2 copies of $large_string (one for $copy and another for the quotes), whereas

このように書くと、$large_string のコピーを二つ($copy とクォートと) 作ります; 一方以下のようにすると:

        my $copy = $large_string;

only makes one copy.

コピーは一つしか作られません。

Ditto for stringifying large arrays:

大きな配列の文字列化でも同じことが言えます:

    {
    local $, = "\n";
    print @big_array;
    }

is much more memory-efficient than either

これは以下のようなものよりメモリ効率がよいです:

    print join "\n", @big_array;

または

    {
    local $" = "\n";
    print "@big_array";
    }

Pass by reference

(リファレンスで渡す)

Pass arrays and hashes by reference, not by value. For one thing, it's the only way to pass multiple lists or hashes (or both) in a single call/return. It also avoids creating a copy of all the contents. This requires some judgement, however, because any changes will be propagated back to the original data. If you really want to mangle (er, modify) a copy, you'll have to sacrifice the memory needed to make one.

配列とハッシュは値ではなく、リファレンスで渡します。これは一つの呼び出し/返り値で複数のリストやハッシュ(やその両方)を渡す唯一の方法です。また、これにより内容全てのコピーを作成しなくてすみます。しかし、これにはいくばくかの判断が必要です; なぜならあらゆる変更が元のデータに伝播するからです。もし本当にコピーをいじりたい(修正したい)のなら、コピーを作るためのメモリを犠牲にする必要があります。

Tie large variables to disk

(大きな変数をディスクに tie する)

For "big" data stores (i.e. ones that exceed available memory) consider using one of the DB modules to store it on disk instead of in RAM. This will incur a penalty in access time, but that's probably better than causing your hard disk to thrash due to massive swapping.

「大きな」データストア(利用可能なメモリ量を超えるようなもの)を扱う時には RAM の代わりにディスクに保存するために DB モジュールのどれかを使うことを考えてください。これはアクセス時間の低下を招きますが、おそらくは大量のスワッピングによってハードディスクが激しく動くよりましです。

ローカルやレキシカルなデータへのポインターを返すことは安全ですか?¶

Yes. Perl's garbage collection system takes care of this so everything works out right.

はい。 Perl のガベージコレクションシステムは全てがうまくいくように考慮されています。

    sub makeone {
        my @a = ( 1 .. 10 );
        return \@a;
    }

    for ( 1 .. 10 ) {
        push @many, makeone();
    }

    print $many[4][5], "\n";

    print "@many\n";

配列やハッシュを解放して私のプログラムを小さくするには?¶

(contributed by Michael Carman)

(Michael Carman によって寄贈されました)

You usually can't. Memory allocated to lexicals (i.e. my() variables) cannot be reclaimed or reused even if they go out of scope. It is reserved in case the variables come back into scope. Memory allocated to global variables can be reused (within your program) by using undef() and/or delete().

それは通常できません。レキシカル(例えば my() 変数) に割り当てられたメモリは、たとえスコープから外れても再請求や再利用されません。これは変数がスコープ内に戻ってくる場合のために保存されます。グローバル変数に割り当てられたメモリは undef() や delete() を使うことで (あなたのプログラム内で)再利用されます。

On most operating systems, memory allocated to a program can never be returned to the system. That's why long-running programs sometimes re- exec themselves. Some operating systems (notably, systems that use mmap(2) for allocating large chunks of memory) can reclaim memory that is no longer used, but on such systems, perl must be configured and compiled to use the OS's malloc, not perl's.

ほとんどのシステムでは、プログラムのために割り付けたメモリは、決してシステムに返されることはありません。これは、長期間動作しているプログラムが時々自分自身を再起動する理由でもあります。一部のオペレーティングシステム(特に大きなメモリの塊を割り付けるときに mmap(2) を使うシステム)では、最早使われていないメモリの塊を回収できますが、そのようなシステムでは、perl を perl 自身ではなく OS の malloc を使うように設定し、コンパイルしなければなりません。

In general, memory allocation and de-allocation isn't something you can or should be worrying about much in Perl.

一般的に、メモリの確保と解放の問題は Perl においてはあまり気にする必要がある問題ではありません。

See also "How can I make my Perl program take less memory?"

"How can I make my Perl program take less memory?" も参照してください。

私の CGI スクリプトをもっと効率よくするには?¶

Beyond the normal measures described to make general Perl programs faster or smaller, a CGI program has additional issues. It may be run several times per second. Given that each time it runs it will need to be re-compiled and will often allocate a megabyte or more of system memory, this can be a killer. Compiling into C isn't going to help you because the process start-up overhead is where the bottleneck is.

普通の Perl プログラムを速くしたり小さくしたりするための基準とは別に、 CGI プログラムには更に別の基準があります。 CGI プログラムは一秒に数回実行される可能性があります。実行する度毎にスクリプトの再コンパイルとシステムメモリを 1 メガバイト以上割りつけることが必要となります; これは問題点となり得ます。 C へコンパイルすることは 助けにはなりません; なぜなら、プロセスのスタートアップ時のオーバーヘッドがボトルネックだからです。

There are three popular ways to avoid this overhead. One solution involves running the Apache HTTP server (available from http://www.apache.org/ ) with either of the mod_perl or mod_fastcgi plugin modules.

このオーバーヘッドを避けるためのポピュラーな手段が二つあります。解決策の一つは Apache HTTP サーバー(http://www.apache.org/ から入手可能)に mod_perl か mod_fastcgi のいずれかのプラグインモジュールを取り込ませて実行させるというものです。

With mod_perl and the Apache::Registry module (distributed with mod_perl), httpd will run with an embedded Perl interpreter which pre-compiles your script and then executes it within the same address space without forking. The Apache extension also gives Perl access to the internal server API, so modules written in Perl can do just about anything a module written in C can. For more on mod_perl, see http://perl.apache.org/

mod_perl と Apache::Registry モジュール(mod_perl と一緒に配布されています)と組み合わせることで、httpd は組み込みの Perl インタプリタと共に実行させるようになります; これで、あなたのスクリプトは事前にコンパイルされ、それを fork 抜きで同じアドレス空間で実行されるようになります。 Apatche エクステンションはまた、Perl に内部サーバー API をアクセスすることを許可するので、Perl で記述されたモジュールは C で書かれたモジュールができることはなんでもできるようになります。 mod_perl に関する詳細は http://perl.apache.org/ を参照してください。

With the FCGI module (from CPAN) and the mod_fastcgi module (available from http://www.fastcgi.com/ ) each of your Perl programs becomes a permanent CGI daemon process.

FCGI モジュール(CPAN にあります)と mod_fastcgi モジュール(http://www.fastcgi.com/ で入手できます)はあなたの Perl プログラムのそれぞれを永続的 CGI デーモンプロセスにします。

Finally, Plack is a Perl module and toolkit that contains PSGI middleware, helpers and adapters to web servers, allowing you to easily deploy scripts which can continue running, and provides flexibility with regards to which web server you use. It can allow existing CGI scripts to enjoy this flexibility and performance with minimal changes, or can be used along with modern Perl web frameworks to make writing and deploying web services with Perl a breeze.

最後に、Plack は web サーバへの PSGI ミドルウェア、ヘルパ、アダプタを含む Perl モジュールで、実行し続けるスクリプトを簡単に配備できるようにし、使用する web サーバに依存しない柔軟性を提供します。これは既存の CGI スクリプトが最小限の変更でこの柔軟性と性能を受けられるようにしたり、Perl で簡単に web サービスを書いたり配備したりするためのモダンな Perl web フレームワークと共に使えるようにします。

These solutions can have far-reaching effects on your system and on the way you write your CGI programs, so investigate them with care.

これらの解決法は、システムおよび CGI プログラムの書き方に幅広い影響を与えることがあるので、慎重に調査してください。

http://www.cpan.org/modules/by-category/15_World_Wide_Web_HTML_HTTP_CGI/ も参照してください。

私の Perl プログラムのソースを隠すには?¶

Delete it. :-) Seriously, there are a number of (mostly unsatisfactory) solutions with varying levels of "security".

削除しましょう。:-) まじめな話、様々な「セキュリティ」レベルを持った幾つかの解決策があります (ほとんどは満足行くものではないでしょう)。

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 のレベルにしておく必要があります。

Some people regard this as a security problem. If your program does insecure things and relies on people not knowing how to exploit those insecurities, it is not secure. It is often possible for someone to determine the insecure things and exploit them without viewing the source. Security through obscurity, the name for hiding your bugs instead of fixing them, is little security indeed.

中にはこれをセキュリティ上の問題であると考えている人もいます。あなたのプログラムが安全でないことを行った場合、そして、人々がそのような安全でないことを暴露する方法を知らないことに頼っているのなら、安全ではないのです。誰かが、安全でないことを見つけだすこととソースを見ることなしにそれを暴露することはしばしば可能となるのです。セキュリティバグを直すのではなくてそのバグを隠すといった、知られていないことに頼るセキュリティ(security through obscurity)は小さなセキュリティの傷です。

You can try using encryption via source filters (Starting from Perl 5.8 the Filter::Simple and Filter::Util::Call modules are included in the standard distribution), but any decent programmer will be able to decrypt it. You can try using the byte code compiler and interpreter described later in perlfaq3, but the curious might still be able to de-compile it. You can try using the native-code compiler described later, but crackers might be able to disassemble it. These pose varying degrees of difficulty to people wanting to get at your code, but none can definitively conceal it (true of every language, not just Perl).

ソースフィルタ(Perl 5.8 からは Filter::Simple と Filter::Util::Call は標準配布物に含まれています)を使った暗号化を試すこともできます; しかし、悪意在るプログラマーはそれを復号化できるかもしれません。あなたは perlfaq3 で後述するバイトコードコンパイラとインタプリタを使うことを試せるかもしれませんが、探りたがりの人はそれを逆コンパイルできるかもしれません。後述するネイティブコードコンパイラを試すこともできますが、クラッカーはそれを逆アセンブルできるかもしれません。これらの手段は、あなたのプログラムを手に入れようとする人達に様々な困難をもたらしますが、誰もそれを決定的に防ぐ障壁にすることはできないのです (Perl のみに限らず、あらゆる言語で真となります)。

It is very easy to recover the source of Perl programs. You simply feed the program to the perl interpreter and use the modules in the B:: hierarchy. The B::Deparse module should be able to defeat most attempts to hide source. Again, this is not unique to Perl.

Perl プログラムのソースを取り出すのはとても簡単です。プログラムを perl インタプリタに渡して B:: 階層のモジュールを使うだけです。 B::Deparse モジュールはソースを隠そうとするほとんどの試みを打ち破るはずです。繰り返しますが、これは Perl に限ったことではありません。

If you're concerned about people profiting from your code, then the bottom line is that nothing but a restrictive license will give you legal security. License your software and pepper it with threatening statements like "This is unpublished proprietary software of XYZ Corp. Your access to it does not give you permission to use it blah blah blah." We are not lawyers, of course, so you should see a lawyer if you want to be sure your license's wording will stand up in court.

あなたが、誰かがあなたのプログラムを元になにか利益を得るのではないかということを考えているのなら、プログラムの最後の行を制限付きライセンスとすれば、あなたに法的な安全性 (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 へコンパイルするには?¶

(contributed by brian d foy)

(brian d foy によって寄贈されました)

In general, you can't do this. There are some things that may work for your situation though. People usually ask this question because they want to distribute their works without giving away the source code, and most solutions trade disk space for convenience. You probably won't see much of a speed increase either, since most solutions simply bundle a Perl interpreter in the final product (but see "How can I make my Perl program run faster?").

一般的には、それはできません。しかし、状況によっては可能な場合もあります。人々は普通、ソースを提供することなく成果を配布したいためにこの質問をします; そしてほとんどの解決法は便利さのためにディスクスペースを犠牲にします。ほとんどの解決法は単に最終製品に Perl インタプリタを同梱しているので、どれを使ってもおそらく大して速度は向上しないでしょう (しかし "How can I make my Perl program run faster?" を参照してください)。

The Perl Archive Toolkit ( http://par.perl.org/ ) is Perl's analog to Java's JAR. It's freely available and on CPAN ( http://search.cpan.org/dist/PAR/ ).

The Perl Archive Toolkit ( http://par.perl.org/ ) は Java における JAR のような Perl 版の類似物です。自由に利用可能で、CPAN にあります ( http://search.cpan.org/dist/PAR/ )。

There are also some commercial products that may work for you, although you have to buy a license for them.

役に立つかもしれないいくつかの商用製品もありますが、それらのライセンスを購入する必要があります。

The Perl Dev Kit ( http://www.activestate.com/Products/Perl_Dev_Kit/ ) from ActiveState can "Turn your Perl programs into ready-to-run executables for HP-UX, Linux, Solaris and Windows."

ActiveState の The Perl Dev Kit ( http://www.activestate.com/Products/Perl_Dev_Kit/ ) は「あなたの Perl プログラムを HP-UX, Linux, Solaris, Windows 用の実行ファイルに変換します。」

Perl2Exe ( http://www.indigostar.com/perl2exe.htm ) is a command line program for converting perl scripts to executable files. It targets both Windows and Unix platforms.

Perl2Exe ( http://www.indigostar.com/perl2exe.htm ) は perl スクリプトを実行可能ファイルに変換するコマンドラインプログラムです。これは Windows と Unix プラットフォームの両方を対象としています。

MS-DOS, NT, etc で '#!perl' が動作するようにするには?¶

For OS/2 just use

OS/2 では単に:

    extproc perl -S -your_switches

as the first line in *.cmd file (-S due to a bug in cmd.exe's "extproc" handling). For DOS one should first invent a corresponding batch file and codify it in ALTERNATE_SHEBANG (see the dosish.h file in the source distribution for more information).

*.cmd ファイルの先頭をこのようにするだけです(-S は、 cmd.exe の "extproc" に関するバグのためです)。 DOS の場合は、適切なバッチファイルを作って ALTERNATE_SHEBANG を行うべきでしょう(詳細は、ソース配布キットにある dosish.h というファイルを参照してください)。

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 のようにします。

Under "Classic" MacOS, a perl program will have the appropriate Creator and Type, so that double-clicking them will invoke the MacPerl application. Under Mac OS X, clickable apps can be made from any #! script using Wil Sanchez' DropScript utility: http://www.wsanchez.net/software/ .

"Classic" MacOS では、perl のプログラムは適切な Creator と Type とを持っているでしょうから、ダブルクリックするだけで MacPerl アプリケーションが起動するでしょう。 Mac OS X では、クリックできるアプリケーションは Wil Sanchez の DropScript utility: http://www.wsanchez.net/software/ を使って任意の #! スクリプトから作成できます。

IMPORTANT!: Whatever you do, PLEASE don't get frustrated, and just throw the perl interpreter into your cgi-bin directory, in order to get your programs working for a web server. This is an EXTREMELY big security risk. Take the time to figure out how to do it correctly.

重要!: あなたが何をするにしても、どうか不満を感じないでください; そして、あなたのプログラムが web サーバのために動作するようにさせるために perl インタプリタを cgi-bin ディレクトリに放り込むようなことはしないでください。これは 非常に 大きなセキュリティ上のリスクとなります。正しく動作させるための方法を考えるための時間を取ってください。

コマンドライン上で便利な Perl プログラムを書けますか?¶

Yes. Read perlrun for more information. Some examples follow. (These assume standard Unix shell quoting rules.)

はい。詳しくは perlrun を読んでください。幾つかのサンプルを以下に挙げておきます。 (ここでは標準のUNIX シェル引用規則に従っていると仮定します。)

    # sum first and last fields
    perl -lane 'print $F[0] + $F[-1]' *

    # identify text files
    perl -le 'for(@ARGV) {print if -f && -T _}' *

    # remove (most) comments from C program
    perl -0777 -pe 's{/\*.*?\*/}{}gs' foo.c

    # make file a month younger than today, defeating reaper daemons
    perl -e '$X=24*60*60; utime(time(),time() + 30 * $X,@ARGV)' *

    # find first unused uid
    perl -le '$i++ while getpwuid($i); print $i'

    # display reasonable manpath
    echo $PATH | perl -nl -072 -e '
    s![^/+]*$!man!&&-d&&!$s{$_}++&&push@m,$_;END{print"@m"}'

OK, the last one was actually an Obfuscated Perl Contest entry. :-)

そう、最後のは Obfuscated Perl コンテストにエントリーされてましたね。 :-)

なぜ私の DOS/Mac/VMS システムでは一行野郎は動かないのでしょうか?¶

The problem is usually that the command interpreters on those systems have rather different ideas about quoting than the Unix shells under which the one-liners were created. On some systems, you may have to change single-quotes to double ones, which you must NOT do on Unix or Plan9 systems. You might also have to change a single % to a %%.

この問題は、そういったシステムのコマンドインタプリタが、一行野郎が作られた環境であるUNIXのシェルの引用規則とは異なるこということです。一部のシステムでは、シングルクォートをダブルクォートに変更する必要があるかもしれません(これは UNIX や Plan9 といったシステムでは してはいけません)。同様に、%を%%に変更する必要もあるかもしれません。

For example:

例を挙げましょう:

    # Unix (including Mac OS X)
    perl -e 'print "Hello world\n"'

    # DOS, etc.
    perl -e "print \"Hello world\n\""

    # Mac Classic
    print "Hello world\n"
     (then Run "Myscript" or Shift-Command-R)

    # MPW
    perl -e 'print "Hello world\n"'

    # VMS
    perl -e "print ""Hello world\n"""

The problem is that none of these examples are reliable: they depend on the command interpreter. Under Unix, the first two often work. Under DOS, it's entirely possible that neither works. If 4DOS was the command shell, you'd probably have better luck like this:

問題は、これらの例の中に信頼できるものがないということです: コマンドインタープリタに依存します。 UNIX では、最初の二つはほとんどの場合動作するでしょう。 DOS では、どれも働かないかもしれません。 4DOS をコマンドシェルとしているのなら、以下のようにするのがよいと思います:

  perl -e "print <Ctrl-x>"Hello world\n<Ctrl-x>""

Under the Mac, it depends which environment you are using. The MacPerl shell, or MPW, is much like Unix shells in its support for several quoting variants, except that it makes free use of the Mac's non-ASCII characters as control characters.

Mac では、あなたが使っている環境に依存します。 MacPerl シェルや MPW は、制御キャラクターのような Mac の非 ASCII キャラクターが自由に使えるという点を除いて、 UNIX シェルのように数種類の引用規則をサポートします。

Using qq(), q(), and qx(), instead of "double quotes", 'single quotes', and `backticks`, may make one-liners easier to write.

ダブルクォート(")、シングルクォート(')、バッククォート(`)の代わりに qq(), q(), qx() をそれぞれ使います; これによって一行野郎を書くことが簡単になるかもしれません。

There is no general solution to all of this. It is a mess.

この件全てに関する一般的な解決策はありません。ごちゃごちゃです。

[Some of this answer was contributed by Kenneth Albanowski.]

[この回答の一部はKenneth Albanowskiから寄せられました。]

Perl による CGI や Web プログラミングについてどこで学べますか?¶

For modules, get the CGI or LWP modules from CPAN. For textbooks, see the two especially dedicated to web stuff in the question on books. For problems and questions related to the web, like "Why do I get 500 Errors" or "Why doesn't it run from the browser right when it runs fine on the command line", see the troubleshooting guides and references in perlfaq9 or in the CGI MetaFAQ:

モジュールなら、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 に関連する問題や疑問は perlfaq9 か CGI MetaFAQ を参照してください:

    L<http://www.perl.org/CGI_MetaFAQ.html>

Looking in to Plack and modern Perl web frameworks is highly recommended, though; web programming in Perl has evolved a long way from the old days of simple CGI scripts.

しかし、Plack およびモダンな Perl web フレームワークの中を見ることを強く勧めます; Perl での web プログラミングは古い時代の単純な CGI スクリプトから大幅に進化しています。

オブジェクト指向の Perl プログラミングはどこで学べますか?¶

A good place to start is perltoot, and you can use perlobj, perlboot, perltoot, perltooc, and perlbot for reference.

始めるにはよい場所は perltootです; リファレンスとして perlobj, perlboot, perltoot, perltooc, perlbot が使えます。

A good book on OO on Perl is the "Object-Oriented Perl" by Damian Conway from Manning Publications, or "Intermediate Perl" by Randal Schwartz, brian d foy, and Tom Phoenix from O'Reilly Media.

Perl でのオブジェクト指向に関するよい本は Manning Publications が出版する Damian Conway による "Object-Oriented Perl" か、 O'Reilly Media が出版する Randal Schwartz, brian d foy, Tom Phoenix による "Intermediate Perl" です。

C と Perl のリンクについてはどこで学べますか?¶

If you want to call C from Perl, start with perlxstut, moving on to perlxs, xsubpp, and perlguts. If you want to call Perl from C, then read perlembed, perlcall, and perlguts. Don't forget that you can learn a lot from looking at how the authors of existing extension modules wrote their code and solved their problems.

もし Perl から C を呼び出したいのなら、perlxstut から始めて perlxs, xsubpp, perlguts へと進みます。 C から Perl を呼び出したいのなら、perlembed, perlcall, perlguts を読みましょう。すでにあるエクステンションの作者がどのようにそれを記述し、どのように彼らの問題を解決したのかを見ることで多くのことが学べるのだということを忘れないでください。

You might not need all the power of XS. The Inline::C module lets you put C code directly in your Perl source. It handles all the magic to make it work. You still have to learn at least some of the perl API but you won't have to deal with the complexity of the XS support files.

XS の力の全てが必要なわけではないかもしれません。 The Inline::C モジュールは Perl のソースの中に C のコードを直接書くことができます。これはこれが動作するための全ての魔法を扱います。それでも少なくとも perl API の一部は学習する必要がありますが、XS サポートファイルの複雑を扱う必要はありません。

perlembed や perlguts なんかを読んだのだけど、私の C プログラムに perl を組み込めません; 何が悪いのでしょうか?¶

Download the ExtUtils::Embed kit from CPAN and run `make test'. If the tests pass, read the pods again and again and again. If they fail, see perlbug and send a bug report with the output of make test TEST_VERBOSE=1 along with perl -V.

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 と一緒に配布されています)。

    perl program 2>diag.out
    splain [-v] [-p] diag.out

or change your program to explain the messages for you:

あるいは、以下のようにしてメッセージを説明的にするようにプログラムを変更します:

    use diagnostics;

または

    use diagnostics -verbose;

MakeMaker ってなんですか?¶

(contributed by brian d foy)

(brian d foy によって寄贈されました)

The ExtUtils::MakeMaker module, better known simply as "MakeMaker", turns a Perl script, typically called Makefile.PL, into a Makefile. The Unix tool make uses this file to manage dependencies and actions to process and install a Perl distribution.

単に "MakeMaker" としてよく知られている ExtUtils::MakeMaker モジュールは、 (典型的には Makefile.PL という名前の) Perl スクリプトを Makefile に変換します。 Unix ツール make は Perl 配布を処理してインストールするための依存と作業を管理します。

AUTHOR AND COPYRIGHT¶

This documentation is free; you can redistribute it and/or modify it under the same terms as Perl itself.

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.