- 名前
- 説明
- 実行しているオペレーティングシステムを見分けるには?
- なぜ exec() は戻ってこないのでしょう?
- キーボード/画面/マウスの凝った機能を使うには?
- 色付きで何かを出力するには?
- リターンキーを待たずにキーのデータを一つ読み取るには?
- キーの入力待ちがあるかどうかチェックするには?
- 画面をクリアするには?
- 画面サイズを得るには?
- ユーザーにパスワードを尋ねるには?
- シリアルポートの読み書きを行うには?
- 暗号化されたパスワードファイルを復号化するには?
- バックグラウンドでプロセスを起動するには?
- 制御文字やシグナルをトラップするには?
- UNIX システムのシャドウパスワードファイルを変更するには?
- 日付や時刻を設定するには?
- 一秒未満の時間に対する sleep() や alarm() をするには?
- 1 秒未満の時間を計るには?
- atexit() や setjmp()/longjmp() をするには? (例外処理)
- なぜ私のソケットプログラムはSystem V (Solaris) ではうまく動かないの? "Protocol not supported"というエラーメッセージの意味するところは?
- Perl から私のシステムに固有の C 関数を呼び出すには?
- ioctl() や syscall() で使うための include ファイルはどこで入手できますか?
- なぜ setuid された perl スクリプトはカーネルの問題について文句を言うのでしょうか?
- あるコマンドに対する双方向のパイプをオープンするには?
- なぜ system() を使ったコマンドの出力を得ることができないのでしょうか?
- 外部コマンドの STDERR を捕捉するには?
- なぜ open() は パイプのオープンに失敗したときにエラーを返さないのでしょうか?
- 無効コンテキストで逆クォートを使うことのなにが悪いのでしょうか?
- シェルの処理をせずに逆クォートを呼び出すには?
- なぜ EOF(UNIX での^D、MS-DOS での^Z)を受け取った後で STDIN から読み込むことができないの?
- 私のシェルスクリプトを perl に変換するには?
- telnet や ftp のセッションを実行するために perl を使うことができますか?
- Perl で expect を書くには?
- “ps”のようなプログラムから、perl のコマンドラインを隠す方法はありますか?
- perl スクリプトの中で、ディレクトリを変更したり環境変数を変更しました。なぜ、スクリプトを終了したときこれらの変更は無効になってしまうの? 変更が反映されるようにするには?
- プロセスの完了を待つことなしにそのファイルハンドルをクローズするには?
- デーモンプロセスを fork() するには?
- 自分が対話的に実行されているかどうかを知るには?
- 遅いイベントをタイムアウトするには?
- CPU のリミットを設定するには?
- UNIX システムでゾンビを回避するには?
- SQL データベースを使うには?
- コントロール-C で system() が exit するようにするには?
- ブロックせずにファイルをオープンするには?
- シェルからと perl からのエラーを見分けるには?
- モジュールを CPAN からインストールするには?
- require と use の間の違いとは?
- 自分自身のモジュール/ライブラリディレクトリを持つには?
- 私のプログラムの置いてある場所をモジュール/ライブラリの検索パスに追加するには?
- 実行時にインクルードパス (@INC) にディレクトリを追加するには?
- socket.ph とは一体何で、それはどこで入手できますか?
- AUTHOR AND COPYRIGHT
名前¶
perlfaq8 - System Interaction
perlfaq8 - システムとの相互作用
説明¶
This section of the Perl FAQ covers questions involving operating system interaction. Topics include interprocess communication (IPC), control over the user-interface (keyboard, screen and pointing devices), and most anything else not related to data manipulation.
FAQ のこのセクションでは、オペレーティングシステムとの対話に関する質問を 扱っています。 これにはプロセス間(IPC)、ユーザーインターフェース (キーボード、スクリーン、ポインティングデバイス)の制御、 その他データ操作に関連しないほとんどの事柄を含みます。
Read the FAQs and documentation specific to the port of perl to your operating system (eg, perlvms, perlplan9, ...). These should contain more detailed information on the vagaries of your perl.
あなたの使っているオペレーティングシステム向けの移植について特有のことは、 それに関する FAQ とドキュメント(perlvms, perlplan9 など)を 読んでください。 そこには、あなたの使う perl についてのより詳しい情報があります。
実行しているオペレーティングシステムを見分けるには?¶
The $^O
variable ($OSNAME
if you use English
) contains an indication of the name of the operating system (not its release number) that your perl binary was built for.
$^O
という変数(use Engish
をしていれば $OSNAME
)は、あなたの使っている perl の実行ファイルがビルドされたオペレーティングシステムの名前 (リリース番号ではありません)の情報を持っています。
なぜ exec() は戻ってこないのでしょう?¶
(contributed by brian d foy)
(brian d foy によって寄贈されました)
The exec
function's job is to turn your process into another command and never to return. If that's not what you want to do, don't use exec
. :)
exec
関数の仕事は、あなたのプロセスを他のコマンドに切り替えて、 決して帰ってこないことです。 もしこれがあなたのしたいことでないなら、exec
を使わないでください。 :)
If you want to run an external command and still keep your Perl process going, look at a piped open
, fork
, or system
.
もし外部コマンドを実行して、かつ Perl プロセスを実行したままにしたい場合は、 パイプ付きの open
, fork
, system
のいずれかを見てください。
キーボード/画面/マウスの凝った機能を使うには?¶
How you access/control keyboards, screens, and pointing devices ("mice") is system-dependent. Try the following modules:
キーボード、画面、ポインティングデバイス(“マウス”)にアクセスしたり それを制御することはシステム依存です。 以下のモジュールを試してみてください:
- Keyboard
-
Term::Cap Standard perl distribution Term::ReadKey CPAN Term::ReadLine::Gnu CPAN Term::ReadLine::Perl CPAN Term::Screen CPAN
- Screen
-
Term::Cap Standard perl distribution Curses CPAN Term::ANSIColor CPAN
- Mouse
-
Tk CPAN
Some of these specific cases are shown as examples in other answers in this section of the perlfaq.
これらの一部の特殊なケースは、このセクションの他の回答の例として 示されています。
色付きで何かを出力するには?¶
In general, you don't, because you don't know whether the recipient has a color-aware display device. If you know that they have an ANSI terminal that understands color, you can use the Term::ANSIColor
module from CPAN:
一般的にはできません。 なぜなら、あなたはディスプレイデバイスに関するレシピについて 何も知らないからです。 もしあなたがカラーの扱える ANSI ターミナルについて知っているのなら、 CPAN にある Term::ANSIColor
モジュールを使うことができます。
use Term::ANSIColor;
print color("red"), "Stop!\n", color("reset");
print color("green"), "Go!\n", color("reset");
Or like this:
あるいは次のようにも書けます:
use Term::ANSIColor qw(:constants);
print RED, "Stop!\n", RESET;
print GREEN, "Go!\n", RESET;
リターンキーを待たずにキーのデータを一つ読み取るには?¶
Controlling input buffering is a remarkably system-dependent matter. On many systems, you can just use the stty command as shown in "getc" in perlfunc, but as you see, that's already getting you into portability snags.
入力バッファを制御するのは非常にシステムに依存したやりかたです。 多くのシステムでは、"getc" in perlfunc にあるように stty コマンドを使うことができますが、今書いた通り 移植性の問題があるのです。
open(TTY, "+</dev/tty") or die "no tty: $!";
system "stty cbreak </dev/tty >/dev/tty 2>&1";
$key = getc(TTY); # perhaps this works
# OR ELSE
sysread(TTY, $key, 1); # probably this does
system "stty -cbreak </dev/tty >/dev/tty 2>&1";
The Term::ReadKey
module from CPAN offers an easy-to-use interface that should be more efficient than shelling out to stty for each key. It even includes limited support for Windows.
CPAN にある Term::ReadKey
モジュールは、stty をキー毎にシェルに 送るよりもより効果的に行ってくれて使うのが簡単なインターフェースを 提供します。 このモジュールは限定的ながら Windows にも対応しています。
use Term::ReadKey;
ReadMode('cbreak');
$key = ReadKey(0);
ReadMode('normal');
However, using the code requires that you have a working C compiler and can use it to build and install a CPAN module. Here's a solution using the standard POSIX
module, which is already on your system (assuming your system supports POSIX).
しかし、このコードを使うには C コンパイラを使えることが条件であり、かつ CPAN モジュールのビルドとインストールができなければなりません。 以下の例は、標準の POSIX
モジュールを使った解決策で、 あなたの使っているシステムが POSIX をサポートしていれば 即使えるものです。
use HotKey;
$key = readkey();
And here's the HotKey
module, which hides the somewhat mystifying calls to manipulate the POSIX termios structures.
そして以下の例は、HotKey
モジュールを使ったものです。 この HotKey モジュールは POSIX の termio 構造体の操作を包み隠します。
# HotKey.pm
package HotKey;
@ISA = qw(Exporter);
@EXPORT = qw(cbreak cooked readkey);
use strict;
use POSIX qw(:termios_h);
my ($term, $oterm, $echo, $noecho, $fd_stdin);
$fd_stdin = fileno(STDIN);
$term = POSIX::Termios->new();
$term->getattr($fd_stdin);
$oterm = $term->getlflag();
$echo = ECHO | ECHOK | ICANON;
$noecho = $oterm & ~$echo;
sub cbreak {
$term->setlflag($noecho); # ok, so i don't want echo either
$term->setcc(VTIME, 1);
$term->setattr($fd_stdin, TCSANOW);
}
sub cooked {
$term->setlflag($oterm);
$term->setcc(VTIME, 0);
$term->setattr($fd_stdin, TCSANOW);
}
sub readkey {
my $key = '';
cbreak();
sysread(STDIN, $key, 1);
cooked();
return $key;
}
END { cooked() }
1;
キーの入力待ちがあるかどうかチェックするには?¶
The easiest way to do this is to read a key in nonblocking mode with the Term::ReadKey
module from CPAN, passing it an argument of -1 to indicate not to block:
最も簡単な方法は、CPAN にある Term::ReadKey
に対して (ブロックを行わないという意味である)-1 を引数に渡して 使用することによって非ブロックモードでキーを読み取るという方法です。
use Term::ReadKey;
ReadMode('cbreak');
if (defined ($char = ReadKey(-1)) ) {
# input was waiting and it was $char
} else {
# no input was waiting
}
ReadMode('normal'); # restore normal tty settings
画面をクリアするには?¶
(contributed by brian d foy)
(brian d foy によって寄贈されました)
To clear the screen, you just have to print the special sequence that tells the terminal to clear the screen. Once you have that sequence, output it when you want to clear the screen.
画面をクリアするには、端末に画面をクリアするように伝える特殊な シーケンスを表示するだけです。 このシーケンスが分かれば、画面をクリアしたいときにこれを出力します。
You can use the Term::ANSIScreen
module to get the special sequence. Import the cls
function (or the :screen
tag):
この特殊なシーケンスを得るためには Term::ANSIScreen
モジュールが 使えます。 cls
関数 (あるいは :screen
タグ) をインポートします:
use Term::ANSIScreen qw(cls);
my $clear_screen = cls();
print $clear_screen;
The Term::Cap
module can also get the special sequence if you want to deal with the low-level details of terminal control. The Tputs
method returns the string for the given capability:
端末制御のための低レベルな詳細を扱いたいなら、 Term::Cap
から特殊シーケンスを得られます。 Tputs
メソッドは、与えられた能力のための文字列を返します:
use Term::Cap;
$terminal = Term::Cap->Tgetent( { OSPEED => 9600 } );
$clear_string = $terminal->Tputs('cl');
print $clear_screen;
On Windows, you can use the Win32::Console
module. After creating an object for the output filehandle you want to affect, call the Cls
method:
Windows では、Win32::Console
モジュールが使えます。 影響を与えたい出力ファイルハンドルのオブジェクトを作った後、 Cls
メソッドを呼び出します:
Win32::Console;
$OUT = Win32::Console->new(STD_OUTPUT_HANDLE);
my $clear_string = $OUT->Cls;
print $clear_screen;
If you have a command-line program that does the job, you can call it in backticks to capture whatever it outputs so you can use it later:
もしこの処理を行うコマンドラインプログラムがあるなら、そのプログラムが 出力するものを得るために逆クォートで呼び出して、後でそれを使うことも できます:
$clear_string = `clear`;
print $clear_string;
画面サイズを得るには?¶
If you have Term::ReadKey
module installed from CPAN, you can use it to fetch the width and height in characters and in pixels:
CPAN にある Term::ReadKey
モジュールをインストールしているのなら、 文字やピクセルでの幅と高さを得ることができます:
use Term::ReadKey;
($wchar, $hchar, $wpixels, $hpixels) = GetTerminalSize();
This is more portable than the raw ioctl
, but not as illustrative:
以下の例は生の ioctl
よりも移植性がありますが、 あまりわかりやすい例ではありません:
require 'sys/ioctl.ph';
die "no TIOCGWINSZ " unless defined &TIOCGWINSZ;
open(TTY, "+</dev/tty") or die "No tty: $!";
unless (ioctl(TTY, &TIOCGWINSZ, $winsize='')) {
die sprintf "$0: ioctl TIOCGWINSZ (%08x: $!)\n", &TIOCGWINSZ;
}
($row, $col, $xpixel, $ypixel) = unpack('S4', $winsize);
print "(row,col) = ($row,$col)";
print " (xpixel,ypixel) = ($xpixel,$ypixel)" if $xpixel || $ypixel;
print "\n";
ユーザーにパスワードを尋ねるには?¶
(This question has nothing to do with the web. See a different FAQ for that.)
(この質問は web とは関係ありません。 それに関しては 別の FAQ を参照してください。)
There's an example of this in "crypt" in perlfunc). First, you put the terminal into "no echo" mode, then just read the password normally. You may do this with an old-style ioctl()
function, POSIX terminal control (see POSIX or its documentation the Camel Book), or a call to the stty program, with varying degrees of portability.
この例が "crypt" in perlfunc にあります。 第一に、端末を“no echo”モードにし、それから通常通りにパスワードを 読み込みます。 これを、古いスタイルの ioctl()
関数を使ってできますし、あるいは POSIX の端末制御(POSIX と、らくだ本を参照してください)を使うことも、 stty プログラムを呼び出すことも可能です(ただしこれは移植性は劣ります)。
You can also do this for most systems using the Term::ReadKey
module from CPAN, which is easier to use and in theory more portable.
あるいはほとんどのシステムで、CPAN にある Term::ReadKey
を使って 行うこともできます。 これは使うのが簡単で、理論的にはより移植性があります。
use Term::ReadKey;
ReadMode('noecho');
$password = ReadLine(0);
シリアルポートの読み書きを行うには?¶
This depends on which operating system your program is running on. In the case of Unix, the serial ports will be accessible through files in /dev; on other systems, device names will doubtless differ. Several problem areas common to all device interaction are the following:
これはプログラムを実行するオペレーティングシステムに依存します。 UNIX の場合、シリアルポートは /dev にあるファイルを通じてアクセスが 可能です。 他のシステムでは、デバイス名は異なったものであることでしょう。 全てのデバイス操作に共通の問題点として以下のものが挙げられます:
- lockfiles
-
(ロックファイル)
Your system may use lockfiles to control multiple access. Make sure you follow the correct protocol. Unpredictable behavior can result from multiple processes reading from one device.
あなたの使っているシステムは、多重アクセスを制御するためにロック ファイルを使用しているかもしれません。 正しい手順に従うようにしてください。 予測のつかない振る舞いは一つのデバイスに対する複数のプロセスの読み出しが 原因かもしれません。
- open mode
-
(オープンモード)
If you expect to use both read and write operations on the device, you'll have to open it for update (see "open" in perlfunc for details). You may wish to open it without running the risk of blocking by using
sysopen()
andO_RDWR|O_NDELAY|O_NOCTTY
from theFcntl
module (part of the standard perl distribution). See "sysopen" in perlfunc for more on this approach.一つのデバイスに対して、読み込みと書き出しの両方の操作ができることを 期待しているのなら、それを更新モード(詳しくは "open" in perlfunc を 参照)でオープンする必要があるでしょう。
sysopen()
とFcntl
モジュールにあるO_RDWR|O_NDELAY|O_NOCTTY
とを使って ブロッキングする危険性なしにオープンを実行したいと考えるかもしれません。 このアプローチに関する詳細は "sysopen" in perlfunc を参照してください。 - end of line
-
(行の末尾)
Some devices will be expecting a "\r" at the end of each line rather than a "\n". In some ports of perl, "\r" and "\n" are different from their usual (Unix) ASCII values of "\012" and "\015". You may have to give the numeric values you want directly, using octal ("\015"), hex ("0x0D"), or as a control-character specification ("\cM").
幾つかのデバイスでは、行の終端に "\n" ではなく "\r" を期待しています。 perl の移植の一部では、"\r" と "\n" は通常の(UNIX の) ASCII 値である "\012" と "\015" とは異なったものになっています。 八進表記 ("\015") や十六進表記("0x0D")、 あるいは制御文字指定 ("\cM") を使って 直接数値を与える必要があるかもしれません。
print DEV "atv1\012"; # wrong, for some devices print DEV "atv1\015"; # right, for some devices
print DEV "atv1\012"; # 一部のデバイスにとっては間違い print DEV "atv1\015"; # 一部のデバイスにとっては正しい
Even though with normal text files a "\n" will do the trick, there is still no unified scheme for terminating a line that is portable between Unix, DOS/Win, and Macintosh, except to terminate ALL line ends with "\015\012", and strip what you don't need from the output. This applies especially to socket I/O and autoflushing, discussed next.
通常のテキストファイルでさえも、"\n" はいたずらを行う可能性があります。 全ての行 を "\015\012" で終わらせ、出力から必要のないものを 取り除くということを除いては、UNIX、DOS/Win、Macintosh との間で 互換性のある行の終端方法は未だに統一されていません。 これは特にソケットの入出力や自動フラッシュで適用されます。 これについては次に述べます。
- flushing output
-
If you expect characters to get to your device when you
print()
them, you'll want to autoflush that filehandle. You can useselect()
and the$|
variable to control autoflushing (see "$|" in perlvar and "select" in perlfunc, or perlfaq5, "How do I flush/unbuffer an output filehandle? Why must I do this?"):デバイスに
print()
した時にそのキャラクタが反映されるようにしたいのなら、 そのハンドルを自動フラッシュするようにしたいでしょう。 自動フラッシュを制御するのに、$|
という変数と、select()
を 使うことができます("$|" in perlvarと"select" in perlfunc または perlfaq5 の "How do I flush/unbuffer an output filehandle? Why must I do this?" を参照してください)。$oldh = select(DEV); $| = 1; select($oldh);
You'll also see code that does this without a temporary variable, as in
以下のように、これを一時変数を使わないで行うコードを見るかもしれません:
select((select(DEV), $| = 1)[0]);
Or if you don't mind pulling in a few thousand lines of code just because you're afraid of a little
$|
variable:$|
というような変数に戸惑いを感じていて、数千行のプログラムを 引っ張りこむことを気にしないのなら以下のようにできます:use IO::Handle; DEV->autoflush(1);
As mentioned in the previous item, this still doesn't work when using socket I/O between Unix and Macintosh. You'll need to hard code your line terminators, in that case.
先のアイテムで述べたように、これでもまだ UNIX と Macintosh の間で ソケット I/O を使った場合にはうまく動作しません。 その場合には、行の終端をハードコーディングする必要があるでしょう。
- non-blocking input
-
If you are doing a blocking
read()
orsysread()
, you'll have to arrange for an alarm handler to provide a timeout (see "alarm" in perlfunc). If you have a non-blocking open, you'll likely have a non-blocking read, which means you may have to use a 4-argselect()
to determine whether I/O is ready on that device (see "select" in perlfunc.ブロッキング
read()
やブロッキングsysread()
を行うのであれば、 タイムアウトを実現するためにalarmハンドラーをアレンジする必要があるでしょう ("alarm" in perlfunc を参照)。 もしノンブロッキング open を持っているのであれば、デバイスが入出力完了の 状態であるかどうかを決定するために四つの引数を取るselect()
を使う必要が あるであろうノンブロッキング read も同様に持っていることでしょう ("select" in perlfuncを参照)。
While trying to read from his caller-id box, the notorious Jamie Zawinski <jwz@netscape.com>
, after much gnashing of teeth and fighting with sysread
, sysopen
, POSIX's tcgetattr
business, and various other functions that go bump in the night, finally came up with this:
caller-id ボックスから読み出すことに挑戦したことで有名な Jamie Zawinski <jwd@netscape.com>
は、 sysread
や sysopen
、POSIX の tcgetattr
その他さまざまな関数を扱い 悪戦苦闘しながら、最終的には以下のようものを作りました:
sub open_modem {
use IPC::Open2;
my $stty = `/bin/stty -g`;
open2( \*MODEM_IN, \*MODEM_OUT, "cu -l$modem_device -s2400 2>&1");
# starting cu hoses /dev/tty's stty settings, even when it has
# been opened on a pipe...
system("/bin/stty $stty");
$_ = <MODEM_IN>;
chomp;
if ( !m/^Connected/ ) {
print STDERR "$0: cu printed `$_' instead of `Connected'\n";
}
}
暗号化されたパスワードファイルを復号化するには?¶
You spend lots and lots of money on dedicated hardware, but this is bound to get you talked about.
特別なハードウェアに非常に多額のお金を掛けてください; しかしこれはあなたが何について話しているかによります。
Seriously, you can't if they are Unix password files--the Unix password system employs one-way encryption. It's more like hashing than encryption. The best you can do is check whether something else hashes to the same string. You can't turn a hash back into the original string. Programs like Crack can forcibly (and intelligently) try to guess passwords, but don't (can't) guarantee quick success.
まじめな話をすると、UNIX のパスワードに対してのものならできません -- UNIX のパスワードシステムは一方向の暗号化を採用しています。 それは暗号化というよりはむしろハッシュ化といえるものです。 あなたがチェックできる最善の方法は、同じ文字列に対する ハッシュかどうかを調べることです。 Crack のようなプログラムは考えられるパスワードを力づくで(そして知的に) 試しますが、即座に成功するものを生成することはしません(できません)。
If you're worried about users selecting bad passwords, you should proactively check when they try to change their password (by modifying passwd(1), for example).
もしあなたが、ユーザーが悪いパスワードを選択してしまうことを 心配しているのであれば、ユーザーが(たとえば passwd(1) を使って)自分の パスワードを変更しようとしたときに積極的にチェックをすべきでしょう。
バックグラウンドでプロセスを起動するには?¶
(contributed by brian d foy)
(brian d foy によって寄贈されました)
There's not a single way to run code in the background so you don't have to wait for it to finish before your program moves on to other tasks. Process management depends on your particular operating system, and many of the techniques are in perlipc.
バックグラウンドでコードを実行するための単一の方法というのはないので、 あなたのプログラムが他のアスクに移動する前に終わるのを待つ必要は ありません。 プロセス管理は使用するオペレーティングシステムに依存していて、 多くのテクニックは perlipc にあります。
Several CPAN modules may be able to help, including IPC::Open2
or IPC::Open3
, IPC::Run
, Parallel::Jobs
, Parallel::ForkManager
, POE
, Proc::Background
, and Win32::Process
. There are many other modules you might use, so check those namespaces for other options too.
IPC::Open2
, IPC::Open3
, IPC::Run
, Parallel::Jobs
, Parallel::ForkManager
, POE
, Proc::Background
, Win32::Process
といった CPAN モジュールが助けになるでしょう。 その他にも使えるかもしれない多くのモジュールがありますので、 これらの名前空間をチェックしてみてください。
If you are on a Unix-like system, you might be able to get away with a system call where you put an &
on the end of the command:
Unix 風のシステムを使っているなら、コマンドの最後に &
を置くことで システムコールから切り離すことができるかもしれません:
system("cmd &")
You can also try using fork
, as described in perlfunc (although this is the same thing that many of the modules will do for you).
perlfunc に記述されているように、fork
を使うこともできます (しかしこれは多くのモジュールがやってくれるのと同じことです)。
- STDIN, STDOUT, and STDERR are shared
-
(STDIN, STDOUT, STDERR は共有されます)
Both the main process and the backgrounded one (the "child" process) share the same STDIN, STDOUT and STDERR filehandles. If both try to access them at once, strange things can happen. You may want to close or reopen these for the child. You can get around this with
open
ing a pipe (see "open" in perlfunc) but on some systems this means that the child process cannot outlive the parent.主プロセスとバックグラウンドプロセス(子プロセス)で同じ STDIN, STDOUT, STDERR のファイルハンドルが共有されます。 両方のプロセスが同時にアクセスしようとすると、 おかしな事が発生するかもしれません。 子プロセス用のこれらのハンドルを、クローズしたり再オープンしたり したくなるかもしれません。 これは、パイプを
open
することで行えますが、 一部のシステムにおいてはこれは子プロセスが親プロセスよりも 長生きすることはできないということになります。 - Signals
-
(シグナル)
You'll have to catch the SIGCHLD signal, and possibly SIGPIPE too. SIGCHLD is sent when the backgrounded process finishes. SIGPIPE is sent when you write to a filehandle whose child process has closed (an untrapped SIGPIPE can cause your program to silently die). This is not an issue with
system("cmd&")
.SIGCHLD シグナルを捕捉する必要があり、可能なら SIGPIPE も 捕捉する必要があるでしょう。 SIGCHLD はバックグラウンドプロセスが終了したときに送られます。 SIGPIPE は既にクローズされている子プロセスを所有するファイルハンドルに 書き込みを行ったときに送られます(トラップされていない SIGPIPE は、 あなたのプログラムを黙って終わらせてしまうかもしれません)。 これは
system("cmd&")
を使ったときには起こりません。 - Zombies
-
(ゾンビ)
You have to be prepared to "reap" the child process when it finishes.
子プロセスが終了したときにそれを“刈り取る”(reap) 準備をする必要があります。
$SIG{CHLD} = sub { wait }; $SIG{CHLD} = 'IGNORE';
You can also use a double fork. You immediately
wait()
for your first child, and the init daemon willwait()
for your grandchild once it exits.2 重 fork も使えます。 あなたは直ちに最初の子に対して
wait()
し、init デーモンは孫が終了するのをwait()
します。unless ($pid = fork) { unless (fork) { exec "what you really wanna do"; die "exec failed!"; } exit 0; } waitpid($pid, 0);
See "Signals" in perlipc for other examples of code to do this. Zombies are not an issue with
system("prog &")
.これを行うサンプルは "Signals" in perlipc を参照してください。 ゾンビは
system("prog &")
を使ったときには発生しません。
制御文字やシグナルをトラップするには?¶
You don't actually "trap" a control character. Instead, that character generates a signal which is sent to your terminal's currently foregrounded process group, which you then trap in your process. Signals are documented in "Signals" in perlipc and the section on "Signals" in the Camel.
実際には制御文字を“トラップ”できません。 その代わりに、その文字が生成して 端末のフォアグラウンドプロセスに送られることになる シグナルがトラップできます。 シグナルは "Signals" in perlipc とらくだ本の "Signal" の章に 説明があります。
You can set the values of the %SIG
hash to be the functions you want to handle the signal. After perl catches the signal, it looks in %SIG
for a key with the same name as the signal, then calls the subroutine value for that key.
%SIG
ハッシュにシグナルを扱いたい関数をセットできます。 perl がシグナルを捕捉した後、perl はシグナルと同じ名前をキーとして %SIG
を 見て、そのキーの値であるサブルーチンを呼び出します。
# as an anonymous subroutine
$SIG{INT} = sub { syswrite(STDERR, "ouch\n", 5 ) };
# or a reference to a function
$SIG{INT} = \&ouch;
# or the name of the function as a string
$SIG{INT} = "ouch";
Perl versions before 5.8 had in its C source code signal handlers which would catch the signal and possibly run a Perl function that you had set in %SIG
. This violated the rules of signal handling at that level causing perl to dump core. Since version 5.8.0, perl looks at %SIG
after the signal has been caught, rather than while it is being caught. Previous versions of this answer were incorrect.
バージョン 5.8 より前の Perl には、シグナルを受け取って、可能なら %SIG
にセットされている Perl の関数を実行する C ソースコードのシグナルハンドラが ありました。 これはこのレベルでのシグナルハンドリングのルールに違反していて、perl の コアダンプを引き起こしていました。 バージョン 5.8.0 から、perl はシグナルを捕捉している間ではなく、シグナルを 捕捉した 後に %SIG
を見ます。 この答えの以前のバージョンは間違っていました。
UNIX システムのシャドウパスワードファイルを変更するには?¶
If perl was installed correctly and your shadow library was written properly, the getpw*()
functions described in perlfunc should in theory provide (read-only) access to entries in the shadow password file. To change the file, make a new shadow password file (the format varies from system to system--see passwd for specifics) and use pwd_mkdb(8)
to install it (see pwd_mkdb for more details).
perl が正しくインストールされていて、かつ、シャドウライブラリが きちんとインストールされていれば、perlfunc で説明されている getpw*()
関数がシャドウパスワードファイルに対する(リードオンリーの) アクセスを提供しています。 ファイルを変更するには、新たなシャドウパスワードファイルを作成して (フォーマットはシステム毎に異なります--詳しくは passwd を参照してください)、pwd_mkdb(8)
を使ってそれをインストールします (詳細は pwd_mkdb を参照のこと)。
日付や時刻を設定するには?¶
Assuming you're running under sufficient permissions, you should be able to set the system-wide date and time by running the date(1)
program. (There is no way to set the time and date on a per-process basis.) This mechanism will work for Unix, MS-DOS, Windows, and NT; the VMS equivalent is set time
.
あなたが十分な権限を持っているとすれば、date(1)
プログラムを実行すれば システム全体の日付や時刻を設定できるはずです (プロセス毎に日付や時刻を設定する方法はありません)。 この機構は、UNIX、MS-DOS、Windows、NT でうまくいくでしょう。 VMS には等価な set time
があります。
However, if all you want to do is change your time zone, you can probably get away with setting an environment variable:
あなたのやりたいことがタイムゾーンの変更であるのなら、 環境変数を変更することでそれができるでしょう。
$ENV{TZ} = "MST7MDT"; # Unixish
$ENV{'SYS$TIMEZONE_DIFFERENTIAL'}="-5" # vms
system "trn comp.lang.perl.misc";
一秒未満の時間に対する sleep() や alarm() をするには?¶
If you want finer granularity than the 1 second that the sleep()
function provides, the easiest way is to use the select()
function as documented in "select" in perlfunc. Try the Time::HiRes
and the BSD::Itimer
modules (available from CPAN, and starting from Perl 5.8 Time::HiRes
is part of the standard distribution).
sleep()
関数が一秒未満の単位での動作をサポートすることを求めているのなら、 "select" in perlfunc にあるように、select()
を使うのが最も単純な方法です。 Time::Hires
と BSD::Itimer
モジュール(CPAN から利用可能ですし、 Perl 5.8 からは Time::HiRes
は標準配布の一部です)も 試してみてください。
1 秒未満の時間を計るには?¶
(contributed by brian d foy)
(brian d foy によって寄贈されました)
The Time::HiRes
module (part of the standard distribution as of Perl 5.8) measures time with the gettimeofday()
system call, which returns the time in microseconds since the epoch. If you can't install Time::HiRes
for older Perls and you are on a Unixish system, you may be able to call gettimeofday(2)
directly. See "syscall" in perlfunc.
(Perl 5.8 から標準配布の一部である) Time::HiRes
モジュールは、 紀元からのマイクロ秒を返す gettimeofday()
システムコールを使って時間を 計測します。 もし古い Perl を使っていて Time::HiRes
をインストールできず、 Unixish を使っているなら、gettimeofday(2)
を直接使えます。 "syscall" in perlfunc を参照してください。
atexit() や setjmp()/longjmp() をするには? (例外処理)¶
Release 5 of Perl added the END block, which can be used to simulate atexit()
. Each package's END block is called when the program or thread ends (see perlmod manpage for more details).
Perl のリリース 5 では、END ブロックが追加されました。 これは atexit()
をシミュレートするのに使うことができます。 各パッケージの END ブロックはプログラム、もしくはスレッド (perlmod を参照してください) が終了したときに呼び出されます (詳しくは perlmod を参照)。
For example, you can use this to make sure your filter program managed to finish its output without filling up the disk:
例を挙げると、あなたのフィルタープログラムが出力を確実に ディスクに送るようにするためには以下のようにできます:
END {
close(STDOUT) || die "stdout close failed: $!";
}
The END
block isn't called when untrapped signals kill the program, though, so if you use END
blocks you should also use
END
ブロックは、トラップされないシグナルが プログラムを強制終了させた場合には呼び出されません。 したがって、END
ブロックを使う場合には同時に以下のようにするべきです:
use sigtrap qw(die normal-signals);
Perl's exception-handling mechanism is its eval()
operator. You can use eval()
as setjmp
and die()
as longjmp
. For details of this, see the section on signals, especially the time-out handler for a blocking flock()
in "Signals" in perlipc or the section on "Signals" in the Camel Book.
Perl の例外処理機構は eval()
演算子です。 setjmp
として eval()
を、longjmp
として die()
を使うことができます。 これに関する詳細は、シグナルに関するセクション、 特に "Signals" in perlipc にあるブロッキング flock()
のための タイムアウトハンドラーと、らくだ本の "Signal" の章を参照してください。
If exception handling is all you're interested in, try the exceptions.pl
library (part of the standard perl distribution).
例外処理そのものに興味があるのなら、exception.pl
ライブラリ (これは標準 perl 配布キットの一部です)を試してみてください。
If you want the atexit() syntax (and an rmexit() as well), try the AtExit module available from CPAN.
atexit() 構文(と、rmexit()) が欲しいのなら、CPAN にある AtExit モジュールを試してみてください。
なぜ私のソケットプログラムはSystem V (Solaris) ではうまく動かないの? "Protocol not supported"というエラーメッセージの意味するところは?¶
Some Sys-V based systems, notably Solaris 2.X, redefined some of the standard socket constants. Since these were constant across all architectures, they were often hardwired into perl code. The proper way to deal with this is to "use Socket" to get the correct values.
一部の System 5 ベースのシステム、特に Solaris 2.x では標準のソケット定数の 幾つかが再定義されています。 これらの定数は全てのアーキテクチャに渡るものであったので、 しばしば perl コードにハードコーディングされています。 これに対処する適切な方法は正しい値を得るために "use Socket" とすることです。
Note that even though SunOS and Solaris are binary compatible, these values are different. Go figure.
SunOS と Solaris とではバイナリ互換性があるにも関らず、 これらの値が異なるということに注意してください。 不思議なことです。
Perl から私のシステムに固有の C 関数を呼び出すには?¶
In most cases, you write an external module to do it--see the answer to "Where can I learn about linking C with Perl? [h2xs, xsubpp]". However, if the function is a system call, and your system supports syscall()
, you can use the syscall
function (documented in perlfunc).
ほとんどの場合、その方法は外部モジュールを作るというものです -- "Where can I learn about linking C with Perl? [h2xs, xsubpp]" の回答を参照してください。 ただし、その関数がシステムコールでありあなたの使っているシステムが syscall()
をサポートしているのであれば、 syscall
関数(perlfunc に説明があります)を使うことができます。
Remember to check the modules that came with your distribution, and CPAN as well--someone may already have written a module to do it. On Windows, try Win32::API
. On Macs, try Mac::Carbon
. If no module has an interface to the C function, you can inline a bit of C in your Perl source with Inline::C
.
一緒に配布されたモジュールや CPAN にあるモジュールをチェックすることを 忘れないでください--誰かが求めるモジュールを既に作っているかもしれません。 Windows では、Win32::API
を試してください。 Mac では、Mac::Carbon
を試してください。 C 関数へのインターフェースを持つモジュールがなければ、 Inline::C
を使って Perl のソースコードにちょっとした C のコードを インライン化できます。
ioctl() や syscall() で使うための include ファイルはどこで入手できますか?¶
Historically, these would be generated by the h2ph
tool, part of the standard perl distribution. This program converts cpp(1)
directives in C header files to files containing subroutine definitions, like &SYS_getitimer
, which you can use as arguments to your functions. It doesn't work perfectly, but it usually gets most of the job done. Simple files like errno.h, syscall.h, and socket.h were fine, but the hard ones like ioctl.h nearly always need to be hand-edited. Here's how to install the *.ph files:
伝統的に、これらのファイルは標準配布に含まれる h2ph
というツールによって 生成されるものです。 このプログラムは C のヘッダーファイルにある cpp(1)
指示子を &SYS_getitimer
のような、関数に対する引数として使うことのできる サブルーチン定義を含むファイルに変換するものです。 これは完璧なものではありませんが、ほとんどの場合には十分な仕事を行います。 errno.h, syscall.h, socket.h のような単純なファイルはよいのですが、 ioctl.h のように難しいものはほとんど常に手で編集する必要があります。 以下の手順は、*.ph ファイルをインストールするためのものです。
1. become super-user
2. cd /usr/include
3. h2ph *.h */*.h
If your system supports dynamic loading, for reasons of portability and sanity you probably ought to use h2xs
(also part of the standard perl distribution). This tool converts C header files to Perl extensions. See perlxstut for how to get started with h2xs
.
あなたの使っているシステムが動的ローディングをサポートしているのであれば、 移植性と健全性(sanity)のために、h2xs
を使うべきでしょう (これも標準の perl 配布キットに含まれています)。 このツールは、C のヘッダーファイルを Perl のエクステンションに変換します。 h2xs
の使い方は perlxstut を参照してください。
If your system doesn't support dynamic loading, you still probably ought to use h2xs
. See perlxstut and ExtUtils::MakeMaker for more information (in brief, just use make perl instead of a plain make to rebuild perl with a new static extension).
あなたの使っているシステムが動的ローディングをサポートしていない 場合であっても、やはり h2xs
を使うべきでしょう。 より詳しい情報は perlxstut と ExtUtils::MakeMaker を参照してください (簡単に言うと、新しい静的エクステションを伴った perl を再ビルドするのに 通常の make を使うのではなく、make perl を使うだけです)。
なぜ setuid された perl スクリプトはカーネルの問題について文句を言うのでしょうか?¶
Some operating systems have bugs in the kernel that make setuid scripts inherently insecure. Perl gives you a number of options (described in perlsec) to work around such systems.
幾つかのオペレーティングシステムは、setuid スクリプトを本質的に 安全でなくするようなカーネルのバグを抱えています。 Perl は、そういったシステムに対処して動作させるための幾つかのオプションを 持っています(perlsec に説明があります)。
あるコマンドに対する双方向のパイプをオープンするには?¶
The IPC::Open2
module (part of the standard perl distribution) is an easy-to-use approach that internally uses pipe()
, fork()
, and exec()
to do the job. Make sure you read the deadlock warnings in its documentation, though (see IPC::Open2). See "Bidirectional Communication with Another Process" in perlipc and "Bidirectional Communication with Yourself" in perlipc
IPC::Open2
モジュール(標準の perl の配布に含まれています)は内部的に pipe()
, fork()
, exec()
を使った使いやすい手法です。 ただし、ドキュメントにあるデッドロックの警告をよく読んでください (IPC::Open2を参照)。 "Bidirectional Communication with Another Process" in perlipc と "Bidirectional Communication with Yourself" in perlipc も参照してください。
You may also use the IPC::Open3
module (part of the standard perl distribution), but be warned that it has a different order of arguments from IPC::Open2
(see IPC::Open3).
IPC::Open3
モジュール(標準配布パッケージに含まれています)も使えますが、 これは IPC::Open2
とは引数の順序が違うということに注意してください (IPC::Open3 を参照してください)。
なぜ system() を使ったコマンドの出力を得ることができないのでしょうか?¶
You're confusing the purpose of system()
and backticks (``). system()
runs a command and returns exit status information (as a 16 bit value: the low 7 bits are the signal the process died from, if any, and the high 8 bits are the actual exit value). Backticks (``) run a command and return what it sent to STDOUT.
system()
の目的と逆クォートの目的を混同しているのでしょう。 system()
はコマンドを実行して、終了ステータス情報(16bit 値として: 下位 7bit は(もしあれば)終了したプロセスからのシグナルで、上位 8bit は 実際の終了ステータス)を返します。 逆クォートはコマンドを実行し、そのコマンドが STDOUT に送ったものを返します。
$exit_status = system("mail-users");
$output_string = `ls`;
外部コマンドの STDERR を捕捉するには?¶
There are three basic ways of running external commands:
外部コマンドを実行する基本的なやり方が三つあります:
system $cmd; # using system()
$output = `$cmd`; # using backticks (``)
open (PIPE, "cmd |"); # using open()
With system()
, both STDOUT and STDERR will go the same place as the script's STDOUT and STDERR, unless the system()
command redirects them. Backticks and open()
read only the STDOUT of your command.
system()
を使った場合の STDOUT と STDERR は、system()
コマンドが リダイレクトを行っていない限りはそれぞれスクリプトが使っていた STDOUT と STDERR へ出力されます。 逆クォートと open()
はコマンドの STDOUT だけを 読み込みます。
You can also use the open3()
function from IPC::Open3
. Benjamin Goldberg provides some sample code:
IPC::Open3
の open3()
関数も使えます。 Benjamin Goldberg がいくつかのサンプルコードを提供しています:
To capture a program's STDOUT, but discard its STDERR:
あるプログラムの STDOUT は捕捉したいが、STDERR は捨てたい場合:
use IPC::Open3;
use File::Spec;
use Symbol qw(gensym);
open(NULL, ">", File::Spec->devnull);
my $pid = open3(gensym, \*PH, ">&NULL", "cmd");
while( <PH> ) { }
waitpid($pid, 0);
To capture a program's STDERR, but discard its STDOUT:
あるプログラムの STDERR は捕捉したいが、STDOUT は捨てたい場合:
use IPC::Open3;
use File::Spec;
use Symbol qw(gensym);
open(NULL, ">", File::Spec->devnull);
my $pid = open3(gensym, ">&NULL", \*PH, "cmd");
while( <PH> ) { }
waitpid($pid, 0);
To capture a program's STDERR, and let its STDOUT go to our own STDERR:
プログラムの STDERR を捕捉してその STDOUT を自身の STDERR に送るには:
use IPC::Open3;
use Symbol qw(gensym);
my $pid = open3(gensym, ">&STDERR", \*PH, "cmd");
while( <PH> ) { }
waitpid($pid, 0);
To read both a command's STDOUT and its STDERR separately, you can redirect them to temp files, let the command run, then read the temp files:
あるコマンドの STDOUT と STDERR を別々に読み込みたい場合、それをテンポラリ ファイルにリダイレクトして、コマンドを実行して、テンポラリファイルから 読み込みます:
use IPC::Open3;
use Symbol qw(gensym);
use IO::File;
local *CATCHOUT = IO::File->new_tmpfile;
local *CATCHERR = IO::File->new_tmpfile;
my $pid = open3(gensym, ">&CATCHOUT", ">&CATCHERR", "cmd");
waitpid($pid, 0);
seek $_, 0, 0 for \*CATCHOUT, \*CATCHERR;
while( <CATCHOUT> ) {}
while( <CATCHERR> ) {}
But there's no real need for both to be tempfiles... the following should work just as well, without deadlocking:
しかし、実際には 両方を テンポラリファイルにするする必要はありません…。 以下のものもデッドロックなしにうまく動きます:
use IPC::Open3;
use Symbol qw(gensym);
use IO::File;
local *CATCHERR = IO::File->new_tmpfile;
my $pid = open3(gensym, \*CATCHOUT, ">&CATCHERR", "cmd");
while( <CATCHOUT> ) {}
waitpid($pid, 0);
seek CATCHERR, 0, 0;
while( <CATCHERR> ) {}
And it'll be faster, too, since we can begin processing the program's stdout immediately, rather than waiting for the program to finish.
そして、これはプログラムの終了を待つのではなく、プログラムの標準出力を直ちに 処理するので、より速いはずです。
With any of these, you can change file descriptors before the call:
これらのどれでも、呼び出しの前にファイル記述子を変更できます:
open(STDOUT, ">logfile");
system("ls");
or you can use Bourne shell file-descriptor redirection:
Bourne シェルのファイル記述子リダイレクションを使うこともできます:
$output = `$cmd 2>some_file`;
open (PIPE, "cmd 2>some_file |");
You can also use file-descriptor redirection to make STDERR a duplicate of STDOUT:
同様に、STDERR を STDOUT の複製にするためにファイル記述子 リダイレクションを使うこともできます。
$output = `$cmd 2>&1`;
open (PIPE, "cmd 2>&1 |");
Note that you cannot simply open STDERR to be a dup of STDOUT in your Perl program and avoid calling the shell to do the redirection. This doesn't work:
STDOUT の複製のために、Perl プログラムの中で単純に STDERR を オープンすることは できない ということと、リダイレクトのための シェルの呼び出しを避けることはできないということに注意してください。 以下の例はうまくいきません:
open(STDERR, ">&STDOUT");
$alloutput = `cmd args`; # stderr still escapes
This fails because the open()
makes STDERR go to where STDOUT was going at the time of the open()
. The backticks then make STDOUT go to a string, but don't change STDERR (which still goes to the old STDOUT).
これは open()
が、STDERR を(open()
が呼び出された時点で)STDOUT が 使っていた場所に対応するようにするので失敗します。 その後で逆クォートは STDOUT(に出力された内容)を文字列にしますが、 STDERR を変更することはしません(これは以前の STDOUT が指していたところです)。
Note that you must use Bourne shell (sh(1)
) redirection syntax in backticks, not csh(1)
! Details on why Perl's system()
and backtick and pipe opens all use the Bourne shell are in the versus/csh.whynot article in the "Far More Than You Ever Wanted To Know" collection in http://www.cpan.org/misc/olddoc/FMTEYEWTK.tgz . To capture a command's STDERR and STDOUT together:
backticlsの中では、csh(1)
のリダイレクト構文ではなく、Bourne shell (sh(1)
) のリダイレクト構文を 使わなければならない ということに 注意してください! なぜ Perl の system()
、逆クォート、パイプオープンの全てで Bourne シェルの ものを使うかは http://www.cpan.org/misc/olddoc/FMTEYEWTK.tgz にある "Far More Than You Ever Wanted To Know" の versus/csh.whynot という記事で 説明されています。 あるコマンドの標準出力と標準エラー出力を両方とも捉えるには:
$output = `cmd 2>&1`; # either with backticks
$pid = open(PH, "cmd 2>&1 |"); # or with an open pipe
while (<PH>) { } # plus a read
To capture a command's STDOUT but discard its STDERR:
あるコマンドの標準出力を捉え、標準エラー出力を捨てるには:
$output = `cmd 2>/dev/null`; # either with backticks
$pid = open(PH, "cmd 2>/dev/null |"); # or with an open pipe
while (<PH>) { } # plus a read
To capture a command's STDERR but discard its STDOUT:
あるコマンドの標準エラー出力を捉え、標準出力を捨てるには:
$output = `cmd 2>&1 1>/dev/null`; # either with backticks
$pid = open(PH, "cmd 2>&1 1>/dev/null |"); # or with an open pipe
while (<PH>) { } # plus a read
To exchange a command's STDOUT and STDERR in order to capture the STDERR but leave its STDOUT to come out our old STDERR:
あるコマンドの標準エラー出力を捉えるために 標準出力と標準エラー出力を入れ替えるが、標準出力に 古い標準エラー出力に出るようにするには:
$output = `cmd 3>&1 1>&2 2>&3 3>&-`; # either with backticks
$pid = open(PH, "cmd 3>&1 1>&2 2>&3 3>&-|");# or with an open pipe
while (<PH>) { } # plus a read
To read both a command's STDOUT and its STDERR separately, it's easiest to redirect them separately to files, and then read from those files when the program is done:
標準出力と標準エラー出力の両方を分けて読み出すには、 別々のファイルにリダイレクトしてしまって、 その後でそのファイルをプログラムから読むというのが最も簡単な方法です:
system("program args 1>program.stdout 2>program.stderr");
Ordering is important in all these examples. That's because the shell processes file descriptor redirections in strictly left to right order.
これらの例では順序が重要です。 なぜなら、シェルがリダイレクトのためのファイル記述子を処理する順序は 正確に左から右へという順になっているからです。
system("prog args 1>tmpfile 2>&1");
system("prog args 2>&1 1>tmpfile");
The first command sends both standard out and standard error to the temporary file. The second command sends only the old standard output there, and the old standard error shows up on the old standard out.
最初のコマンドは標準出力と標準エラー出力の両方を一時ファイルに送ります。 二番目のコマンドは古い標準出力だけをファイルへと送り、古い標準エラー出力は 古い標準出力へと送り出します。
なぜ open() は パイプのオープンに失敗したときにエラーを返さないのでしょうか?¶
If the second argument to a piped open()
contains shell metacharacters, perl fork()
s, then exec()
s a shell to decode the metacharacters and eventually run the desired program. If the program couldn't be run, it's the shell that gets the message, not Perl. All your Perl program can find out is whether the shell itself could be successfully started. You can still capture the shell's STDERR and check it for error messages. See "How can I capture STDERR from an external command?" elsewhere in this document, or use the IPC::Open3
module.
パイプされた open()
の第二引数にシェルのメタ文字が含まれている場合、 perl は fork()
し、メタ文字をデコードするためにシェルを exec()
し、 最終的に必要なプログラムを実行します。 このプログラムが実行できない場合、メッセージを得るのはシェルであって、 Perl ではありません。 あなたの Perl プログラムがわかることはシェル自身が正しく開始されたかどうか だけです。 エラーメッセージのためにシェルの STDERR を捕捉してチェックするという方法は あります。 この文書の別の場所にある "How can I capture STDERR from an external command?" を参照するか、IPC::Open3
モジュールを使ってください。
If there are no shell metacharacters in the argument of open()
, Perl runs the command directly, without using the shell, and can correctly report whether the command started.
open()
の引数にシェルのメタ文字がないなら、Perl はコマンドをシェルを使わずに 直接実行し、コマンドが開始したかどうかを正しく報告できます。
無効コンテキストで逆クォートを使うことのなにが悪いのでしょうか?¶
Strictly speaking, nothing. Stylistically speaking, it's not a good way to write maintainable code. Perl has several operators for running external commands. Backticks are one; they collect the output from the command for use in your program. The system
function is another; it doesn't do this.
厳密に言えばありません。 形式的に言えば、保守しやすいコードを書くための良い方法ではありません。 Perl は外部コマンドを実行するためのいくつかの演算子があります。 逆クォートはその一つです; これはコマンドからの出力を、自身のプログラムで 使うために収集します。 system
関数はもう一つのものです; これはコマンドからの出力を収集しません。
Writing backticks in your program sends a clear message to the readers of your code that you wanted to collect the output of the command. Why send a clear message that isn't true?
プログラム中に逆クォートを書くことで、そのコマンドの出力を使いたいという はっきりしたメッセージをあなたのコードの読者に送ります。 なぜ正しくないはっきりしたメッセージを送るのですか?
Consider this line:
以下のような行を考えてみましょう:
`cat /etc/termcap`;
You forgot to check $?
to see whether the program even ran correctly. Even if you wrote
プログラムが正しく実行されたかどうかを確認するために $?
を見るのを忘れています。
print `cat /etc/termcap`;
this code could and probably should be written as
このコードは、以下のように書くべきでしょう
system("cat /etc/termcap") == 0
or die "cat program failed!";
which will echo the cat command's output as it is generated, instead of waiting until the program has completed to print it out. It also checks the return value.
これは、プログラムが出力を終えるのを待つのではなく、cat コマンドの出力が 生成される毎にエコーします。 これはまたその戻り値のチェックも行います。
system
also provides direct control over whether shell wildcard processing may take place, whereas backticks do not.
system() はまた、シェルのワイルドカード処理を行えるかどうかを直接 制御しますが、逆クォートはそういった制御は行いません。
シェルの処理をせずに逆クォートを呼び出すには?¶
This is a bit tricky. You can't simply write the command like this:
ちょっとトリッキーになります。 単純に以下のようにはコマンドを書けません:
@ok = `grep @opts '$search_string' @filenames`;
As of Perl 5.8.0, you can use open()
with multiple arguments. Just like the list forms of system()
and exec()
, no shell escapes happen.
Perl 5.8.0 から、複数の引数の open()
を使えます。 リスト形式の system()
や exec()
と同様に、シェルエスケープは 起きません。
open( GREP, "-|", 'grep', @opts, $search_string, @filenames );
chomp(@ok = <GREP>);
close GREP;
You can also:
以下のようにもできます:
my @ok = ();
if (open(GREP, "-|")) {
while (<GREP>) {
chomp;
push(@ok, $_);
}
close GREP;
} else {
exec 'grep', @opts, $search_string, @filenames;
}
Just as with system()
, no shell escapes happen when you exec()
a list. Further examples of this can be found in "Safe Pipe Opens" in perlipc.
system()
を使ったときと同じく、シェルエスケープは exec()
のリストに 対して行われません。 さらなる例が "Safe Pipe Opens" in perlipc にあります。
Note that if you're using Windows, no solution to this vexing issue is even possible. Even if Perl were to emulate fork()
, you'd still be stuck, because Windows does not have an argc/argv-style API.
もしあなたが Windows を使っているのなら、この悩ましい問題を 解決する方法は全くありません。 たとえ Perl が fork()
をエミュレートしたとしても、まだうまくいきません。 なぜならマイクロソフトは argc/argv 形式の API を提供していないからです。
なぜ EOF(UNIX での^D、MS-DOS での^Z)を受け取った後で STDIN から読み込むことができないの?¶
This happens only if your perl is compiled to use stdio instead of perlio, which is the default. Some (maybe all?) stdios set error and eof flags that you may need to clear. The POSIX
module defines clearerr()
that you can use. That is the technically correct way to do it. Here are some less reliable workarounds:
これは、デフォルトである perlio ではなく、stdio を使ってコンパイルされた perl でのみ起こります。 一部の(おそらく全ての?) stdio ではエラーフラグと eof フラグがセットされ、 それをクリアする必要があるからです。 POSIX モジュールはこのために使える clearerr() を定義しています。 これは、フラグをクリアするための技術的に正しい方法です。 以下の方法はこれよりは信頼性にかけるやり方です:
-
Try keeping around the seekpointer and go there, like this:
以下の例のように、シークポインタを保存しておいてそこへ移動します:
$where = tell(LOG); seek(LOG, $where, 0);
-
If that doesn't work, try seeking to a different part of the file and then back.
上のやりかたがだめなら、一度ファイルの別の部分にシークして、それから 元の場所にシークするようにします。
-
If that doesn't work, try seeking to a different part of the file, reading something, and then seeking back.
これでもだめなら、ファイルの別の部分にシークして何かを読み出し、それから 元の場所にシークするようにします。
-
If that doesn't work, give up on your stdio package and use sysread.
これでだめなら stdio パッケージで行うことはあきらめて、sysread を使います。
私のシェルスクリプトを perl に変換するには?¶
Learn Perl and rewrite it. Seriously, there's no simple converter. Things that are awkward to do in the shell are easy to do in Perl, and this very awkwardness is what would make a shell->perl converter nigh-on impossible to write. By rewriting it, you'll think about what you're really trying to do, and hopefully will escape the shell's pipeline datastream paradigm, which while convenient for some matters, causes many inefficiencies.
Perl を学び、自分で書き直しましょう。 まじめな話、単純なコンバータというものはありません。 シェルで行うには不格好になるようなことも Perl では簡単に行うことができ、 そして、このとても不格好なことがシェル→ perl コンバーターを作製することを ほとんど不可能なことにしているのです。 自分で書き換えをすることで、あなたは自分が本当に試すべきことについて 考えるようになり、シェルの(便利なときもあるものの多くの非効率を持ち込む) パイプラインデータストリームパラダイムから逃れることができるでしょう。
telnet や ftp のセッションを実行するために perl を使うことができますか?¶
Try the Net::FTP
, TCP::Client
, and Net::Telnet
modules (available from CPAN). http://www.cpan.org/scripts/netstuff/telnet.emul.shar will also help for emulating the telnet protocol, but Net::Telnet
is quite probably easier to use.
Net::FTP
, TCP::Client
, Net::Telnet
といったモジュール(CPAN で入手可能です)を 試してみてください。 http://www.cpan.org/scripts/netstuff/telnet.emul.shar も telnet プロトコルを エミュレートする助けになるでしょうが、Net::Telnet
は使うのがとても簡単です。
If all you want to do is pretend to be telnet but don't need the initial telnet handshaking, then the standard dual-process approach will suffice:
あなたのやりたいことが telnet のふりをすることであっても初期化時の telnet のハンドシェイクを必要としないのであれば、 標準的な dual-process アプローチで十分でしょう。
use IO::Socket; # new in 5.004
$handle = IO::Socket::INET->new('www.perl.com:80')
or die "can't connect to port 80 on www.perl.com: $!";
$handle->autoflush(1);
if (fork()) { # XXX: undef means failure
select($handle);
print while <STDIN>; # everything from stdin to socket
} else {
print while <$handle>; # everything from socket to stdout
}
close $handle;
exit;
Perl で expect を書くには?¶
Once upon a time, there was a library called chat2.pl (part of the standard perl distribution), which never really got finished. If you find it somewhere, don't use it. These days, your best bet is to look at the Expect module available from CPAN, which also requires two other modules from CPAN, IO::Pty
and IO::Stty
.
昔々、chat2.pl と呼ばれたライブラリがありました(これは標準の perl 配布キットに含まれます)。 もしこれをどこかで見つけても使ってはいけません。 今日では、CPAN にある IO::Pty
や IO::Stty
といった ライブラリを探すのが最善でしょう。
“ps”のようなプログラムから、perl のコマンドラインを隠す方法はありますか?¶
First of all note that if you're doing this for security reasons (to avoid people seeing passwords, for example) then you should rewrite your program so that critical information is never given as an argument. Hiding the arguments won't make your program completely secure.
まず初めに、あなたが(たとえば他人がパスワードを除くのを避けるためなどの) セキュリティ上の理由でそれを行おうとしてるのであれば、 重要な情報が引数として与えられることがないようにプログラムを 書き直すべきだということに注意してください。 引数を隠すことは、あなたのプログラムを完全に安全なものにすることは ありません。
To actually alter the visible command line, you can assign to the variable $0 as documented in perlvar. This won't work on all operating systems, though. Daemon programs like sendmail place their state there, as in:
外部から見えるコマンドラインを実際に書き換えるために、perlvar で 説明されているように $0 という変数に代入することができます。 ただし、これはすべてのオペレーティングシステムで実行できるというものでは ありません。 sendmail のようなデーモンプログラムは以下の例のように状態を設定します:
$0 = "orcus [accepting connections]";
perl スクリプトの中で、ディレクトリを変更したり環境変数を変更しました。なぜ、スクリプトを終了したときこれらの変更は無効になってしまうの? 変更が反映されるようにするには?¶
- Unix
-
In the strictest sense, it can't be done--the script executes as a different process from the shell it was started from. Changes to a process are not reflected in its parent--only in any children created after the change. There is shell magic that may allow you to fake it by
eval()
ing the script's output in your shell; check out the comp.unix.questions FAQ for details.もっとも厳密な意味で言うと、それはできません--スクリプトはそれを 起動したシェルとは異なるプロセスで実行されるのです。 あるプロセスに対する変更はその親に反映されることはありません --変更した後で生成された子プロセスに対してのみ反映されます。 あなたの使っているシェルにおいてスクリプトの出力を
eval()
することによって、 お望みのことをしたように見せかけるシェルマジック (shell magic)があります。 詳しくは comp.unix.questions FAQを調べてください。
プロセスの完了を待つことなしにそのファイルハンドルをクローズするには?¶
Assuming your system supports such things, just send an appropriate signal to the process (see "kill" in perlfunc). It's common to first send a TERM signal, wait a little bit, and then send a KILL signal to finish it off.
あなたの使っているシステムがそういった機能をサポートしていると仮定すると、 そのプロセスに対して適切なシグナルを送るだけです ("kill" in perlfunc を参照してください)。 最初にTERMシグナルを送り、ちょっとだけ待って、 終了させるために KILL シグナルを送るというのが一般的なものです。
デーモンプロセスを fork() するには?¶
If by daemon process you mean one that's detached (disassociated from its tty), then the following process is reported to work on most Unixish systems. Non-Unix users should check their Your_OS::Process module for other solutions.
あなたのいうデーモンプロセスが detach されている(tty と 結び付けられていない)ものであれば、以下の手順がほとんどの UNIX 的な システムで動作するということが報告されています。 非 UNIX ユーザーは Your_OS::Process モジュールで他の解決策を あたるべきでしょう。
-
Open /dev/tty and use the TIOCNOTTY ioctl on it. See tty for details. Or better yet, you can just use the
POSIX::setsid()
function, so you don't have to worry about process groups./dev/tty をオープンし、それに TIOCNOTTY ioctl を使います。 詳しくは tty を参照してください。 そのほかもっと良いのは、
POSIX::setsid()
関数を使うことです。 これによってプロセスグループに関して思い煩う必要がなくなります。 -
Change directory to /
/ へディレクトリを変更します。
-
Reopen STDIN, STDOUT, and STDERR so they're not connected to the old tty.
STDIN、STDOUT、STDERR を再オープンします。 これでこれらのハンドルは以前の tty とは結び付けらていない状態になります。
-
Background yourself like this:
以下のようにしてバックグラウンドにします:
fork && exit;
The Proc::Daemon
module, available from CPAN, provides a function to perform these actions for you.
CPAN で入手できる Proc::Daemon
モジュールはこれらの操作を 行ってくれる関数を提供しています。
自分が対話的に実行されているかどうかを知るには?¶
(contributed by brian d foy)
(brian d foy によって寄贈されました)
This is a difficult question to answer, and the best answer is only a guess.
これは答えるのが難しい質問で、最良の答えは単なる推測です。
What do you really want to know? If you merely want to know if one of your filehandles is connected to a terminal, you can try the -t
file test:
本当に知りたいことは何でしょう? 単にファイルハンドルの一つが端末と接続しているかどうかを知りたいなら、 -t
ファイルテストを試すことができます:
if( -t STDOUT ) {
print "I'm connected to a terminal!\n";
}
However, you might be out of luck if you expect that means there is a real person on the other side. With the Expect
module, another program can pretend to be a person. The program might even come close to passing the Turing test.
しかし、その先に実際の人間がいることを想定するなら、うまく いかないかもしれません。 Expect
では、他のプログラムは人間である振りをします。 プログラムはチューリングテストに通過しそうになるかもしれません。
The IO::Interactive
module does the best it can to give you an answer. Its is_interactive
function returns an output filehandle; that filehandle points to standard output if the module thinks the session is interactive. Otherwise, the filehandle is a null handle that simply discards the output:
IO::Interactive
モジュールが答えとして最良のものです。 この is_interactive
関数は出力ファイルハンドルを返します; このファイルハンドルは、モジュールがセッションが対話的であると考えた 場合には、標準出力を示します。 さもなければ、ファイルハンドルは、単に出力が捨てられる空のハンドルです:
use IO::Interactive;
print { is_interactive } "I might go to standard output!\n";
This still doesn't guarantee that a real person is answering your prompts or reading your output.
これままだ実際の人間がプロンプトに答えたり出力を読んだりするのが 実際の人間であることを保証しません。
If you want to know how to handle automated testing for your distribution, you can check the environment. The CPAN Testers, for instance, set the value of AUTOMATED_TESTING
:
あなたの配布での自動化テストの扱う方法を知りたいなら、環境を チェックしてください。 例えば、CPAN Testers は AUTOMATED_TESTING
の値を設定します:
unless( $ENV{AUTOMATED_TESTING} ) {
print "Hello interactive tester!\n";
}
遅いイベントをタイムアウトするには?¶
Use the alarm()
function, probably in conjunction with a signal handler, as documented in "Signals" in perlipc and the section on "Signals" in the Camel. You may instead use the more flexible Sys::AlarmCall
module available from CPAN.
"Signals" in perlipc やらくだ本の "Signal" の章で説明されているように、 alarm()
関数と、おそらくはシグナルハンドラーを組み合わせて使います。 この代わりに、CPAN にあるより柔軟性のある Sys::AlarmCall
モジュールを使うこともできます。
The alarm()
function is not implemented on all versions of Windows. Check the documentation for your specific version of Perl.
alarm()
関数は Windows の全てのバージョンで実装されているわけではありません。 あなたの特定のバージョンの Perl のドキュメントをチェックしてください。
CPU のリミットを設定するには?¶
(contributed by Xho)
(Xho によって寄贈されました)
Use the BSD::Resource
module from CPAN. As an example:
CPAN にある BSD::Resource
モジュールを使います。 例として:
use BSD::Resource;
setrlimit(RLIMIT_CPU,10,20) or die $!;
This sets the soft and hard limits to 10 and 20 seconds, respectively. After 10 seconds of time spent running on the CPU (not "wall" time), the process will be sent a signal (XCPU on some systems) which, if not trapped, will cause the process to terminate. If that signal is trapped, then after 10 more seconds (20 seconds in total) the process will be killed with a non-trappable signal.
これはソフト制限とハード制限をそれぞれ 10 秒と 20 秒にセットします。 CPU が 10 秒の時間を消費後("wall" 時間ではありません)、プロセスはシグナル (システムによっては XCPU)を送り、トラップされなければ、これによりプロセスは 終了します。 シグナルがトラップされると、さらに 10 秒(合計 20 秒)経過後、プロセスは ブロック不可シグナルで kill されます。
See the BSD::Resource
and your systems documentation for the gory details.
詳細については BSD::Resource
とあなたのシステムのドキュメントを 参照してください。
UNIX システムでゾンビを回避するには?¶
Use the reaper code from "Signals" in perlipc to call wait()
when a SIGCHLD is received, or else use the double-fork technique described in "How do I start a process in the background?" in perlfaq8.
SIGCHLD を受け取ったときに wait()
を呼び出すように "Signals" in perlipc に ある刈り取り機プログラム (reaper code) を使うか、 "How do I start a process in the background?" in perlfaq8 で 説明されている double-fork テクニックを使います。
SQL データベースを使うには?¶
The DBI
module provides an abstract interface to most database servers and types, including Oracle, DB2, Sybase, mysql, Postgresql, ODBC, and flat files. The DBI module accesses each database type through a database driver, or DBD. You can see a complete list of available drivers on CPAN: http://www.cpan.org/modules/by-module/DBD/ . You can read more about DBI on http://dbi.perl.org .
DBI
モジュールはほとんどのデータベースサーバと型に対する抽象 インターフェースを提供します; これには Oracle, DB2, Sybase, mysql, Postgresql, ODBC, フラットファイルを含みます。 DBI モジュールは、DBD と呼ばれるデータベースドライバを通して各データベース 型にアクセスします。 利用可能なドライバの完全な一覧は CPAN (http://www.cpan.org/modules/by-module/DBD/) にあります。 DBI に関するさらなる情報は http://dbi.perl.org にあります。
Other modules provide more specific access: Win32::ODBC
, Alzabo
, iodbc
, and others found on CPAN Search: http://search.cpan.org .
その他のモジュールはより具体的なアクセスを提供します: Win32::ODBC
, Alzabo
, iodbc
などは CPAN Search (http://search.cpan.org) で 見つけられます。
コントロール-C で system() が exit するようにするには?¶
You can't. You need to imitate the system()
call (see perlipc for sample code) and then have a signal handler for the INT signal that passes the signal on to the subprocess. Or you can check for it:
できません。 system()
呼び出しを模倣する必要があり(perlipc のサンプルコードを 参照してください)、サブプロセスでのシグナルを送る INT シグナルのためのシグナルハンドラーを持つ必要があります。 あるいは、以下のようにしてチェックすることもできます:
$rc = system($cmd);
if ($rc & 127) { die "signal death" }
ブロックせずにファイルをオープンするには?¶
If you're lucky enough to be using a system that supports non-blocking reads (most Unixish systems do), you need only to use the O_NDELAY
or O_NONBLOCK
flag from the Fcntl
module in conjunction with sysopen()
:
幸運にもあなたの使っているシステムがノンブロッキング読み出し (ほとんどの Unix 的システムはサポートしています)をサポートしているのであれば、 Fcntl
モジュールの O_NDELAY
や O_NONBLOCK
というフラグを sysopen()
と一緒に使うだけです。
use Fcntl;
sysopen(FH, "/foo/somefile", O_WRONLY|O_NDELAY|O_CREAT, 0644)
or die "can't open /foo/somefile: $!":
シェルからと perl からのエラーを見分けるには?¶
(answer contributed by brian d foy)
(答えは brian d foy によって寄贈されました)
When you run a Perl script, something else is running the script for you, and that something else may output error messages. The script might emit its own warnings and error messages. Most of the time you cannot tell who said what.
あなたが Perl スクリプトを実行すると、他の誰かがあなたのためにスクリプトを 動かします; そしてその他の誰かがエラーメッセージを出すことがあります。 スクリプトも自身の警告やエラーメッセージを出すかもしれません。 ほとんどの場合、それを言っているのが誰かは教えてもらえません。
You probably cannot fix the thing that runs perl, but you can change how perl outputs its warnings by defining a custom warning and die functions.
あなたが perl を実行しているものを修正することはおそらくできませんが、 独自の警告と die の関数を定義することで、perl がどのように警告を 出力するかを変えることはできます。
Consider this script, which has an error you may not notice immediately.
すぐには気付かないかもしれない誤りを含むこのスクリプトを考えてみてください。
#!/usr/locl/bin/perl
print "Hello World\n";
I get an error when I run this from my shell (which happens to be bash). That may look like perl forgot it has a print()
function, but my shebang line is not the path to perl, so the shell runs the script, and I get the error.
これを私のシェル(たまたま bash でした)で実行するとエラーが表示されます。 これは perl が print()
関数を忘れてしまったかのように見えますが、 #! 行の perl へのパスが間違っているので、シェルがこのスクリプトを実行し、 エラーが表示されます。
$ ./test
./test: line 3: print: command not found
A quick and dirty fix involves a little bit of code, but this may be all you need to figure out the problem.
素早く汚い修正には少しコードが必要ですが、おそらく問題を見つけ出すのに 必要なものが全てあるでしょう。
#!/usr/bin/perl -w
BEGIN {
$SIG{__WARN__} = sub{ print STDERR "Perl: ", @_; };
$SIG{__DIE__} = sub{ print STDERR "Perl: ", @_; exit 1};
}
$a = 1 + undef;
$x / 0;
__END__
The perl message comes out with "Perl" in front. The BEGIN
block works at compile time so all of the compilation errors and warnings get the "Perl:" prefix too.
perl のメッセージは先頭に "Perl" を付けて出力されます。 BEGIN
ブロックはコンパイル時に動作するので、全てのコンパイル時のエラーと 警告にも "Perl:" の接頭辞がつきます。
Perl: Useless use of division (/) in void context at ./test line 9.
Perl: Name "main::a" used only once: possible typo at ./test line 8.
Perl: Name "main::x" used only once: possible typo at ./test line 9.
Perl: Use of uninitialized value in addition (+) at ./test line 8.
Perl: Use of uninitialized value in division (/) at ./test line 9.
Perl: Illegal division by zero at ./test line 9.
Perl: Illegal division by zero at -e line 3.
If I don't see that "Perl:", it's not from perl.
"Perl:" という文字がなければ、perl が出しているものではありません。
You could also just know all the perl errors, and although there are some people who may know all of them, you probably don't. However, they all should be in the perldiag manpage. If you don't find the error in there, it probably isn't a perl error.
単に全ての perl のエラーを知るという方法もありますが、(全てのエラーを 知っている人もいるかもしれませんが)おそらくあなたは知らないでしょう。 しかし、これら全ては perldiag マニュアルページにあるはずです。 もしエラーがここになければ、それはおそらく perl のエラーではありません。
Looking up every message is not the easiest way, so let perl to do it for you. Use the diagnostics pragma with turns perl's normal messages into longer discussions on the topic.
全てのメッセージを探すというのは最も簡単な方法ではないので、その作業は perl にさせます。 perl の通常のメッセージを、より長い説明に変更する diagnostics プラグマを 使います。
use diagnostics;
If you don't get a paragraph or two of expanded discussion, it might not be perl's message.
段落一つか二つの追加の議論が表示されなければ、それは perl のメッセージでは ないでしょう。
モジュールを CPAN からインストールするには?¶
(contributed by brian d foy)
(brian d foy によって寄贈されました)
The easiest way is to have a module also named CPAN do it for you by using the cpan
command the comes with Perl. You can give it a list of modules to install:
最も単純な方法は、Perl と同梱されている cpan
コマンドを使って、この仕事を してくれる CPAN モジュールを入手することです。 インストールするモジュールの一覧を与えます:
$ cpan IO::Interactive Getopt::Whatever
If you prefer CPANPLUS
, it's just as easy:
CPANPLUS
が好みなら、やはり簡単です:
$ cpanp i IO::Interactive Getopt::Whatever
If you want to install a distribution from the current directory, you can tell CPAN.pm
to install .
(the full stop):
現在のディレクトリからディストリビューションをインストールしたいなら、 CPAN.pm
に .
をインストールするように知らせることができます (完全停止):
$ cpan .
See the documentation for either of those commands to see what else you can do.
その他に出来ることについてはこれらのコマンドの文書を参照してください。
If you want to try to install a distribution by yourself, resolving all dependencies on your own, you follow one of two possible build paths.
全ての依存を自分で解決して、配布を自分自身でインストールしてみたい場合は、 二つのビルド方法のどちらかに従います。
For distributions that use Makefile.PL:
Makefile.PL を使う配布では:
$ perl Makefile.PL
$ make test install
Build.PL を使う配布では:
$ perl Build.PL
$ ./Build test
$ ./Build install
Some distributions may need to link to libraries or other third-party code and their build and installation sequences may be more complicated. Check any README or INSTALL files that you may find.
一部の配布ではライブラリはその他のサードパーティのコードへのリンクが 必要であったり、ビルドとインストールの手順がもっと複雑な場合もあります。 見付かった README や INSTALL ファイルをチェックしてください。
require と use の間の違いとは?¶
(contributed by brian d foy)
(brian d foy によって寄贈されました)
Perl runs require
statement at run-time. Once Perl loads, compiles, and runs the file, it doesn't do anything else. The use
statement is the same as a require
run at compile-time, but Perl also calls the import
method for the loaded package. These two are the same:
Perl は require
文を実行時に実行します。 一旦 Perl がロードされ、コンパイルされ、ファイルが実行されると、 他に何もしません。 use
文は require
と同じことをコンパイル時に行いますが、 Perl はまたロードされたパッケージの import
メソッドを呼び出します。 以下の二つは同じです:
use MODULE qw(import list);
BEGIN {
require MODULE;
MODULE->import(import list);
}
However, you can suppress the import
by using an explicit, empty import list. Both of these still happen at compile-time:
しかし、明示的に空のインポートリストを使うことで、import
を 抑制できます。 これらはどちらもやはりコンパイル時に起こります:
use MODULE ();
BEGIN {
require MODULE;
}
Since use
will also call the import
method, the actual value for MODULE
must be a bareword. That is, use
cannot load files by name, although require
can:
use
は import
メソッドの呼び出しも行うので、 MODULE
の実際の値は裸の単語でなければなりません。 これは、use
は名前でファイルをロード出来ませんが、 require
ではできます:
require "$ENV{HOME}/lib/Foo.pm"; # no @INC searching!
See the entry for use
in perlfunc for more details.
さらなる詳細については perlfunc の use
の項目を参照してください。
自分自身のモジュール/ライブラリディレクトリを持つには?¶
When you build modules, tell Perl where to install the modules.
モジュールを作成するときに、Perl にモジュールをインストールする場所を 指定します。
For Makefile.PL
-based distributions, use the INSTALL_BASE option when generating Makefiles:
Makefile.PL
-ベースの配布では、Makefile の生成時に INSTALL_BASE オプションを使ってください:
perl Makefile.PL INSTALL_BASE=/mydir/perl
You can set this in your CPAN.pm
configuration so modules automatically install in your private library directory when you use the CPAN.pm shell:
CPAN.pm シェルを使ったときに、自動的にモジュールを自分のプライベートな ディレクトリにインストールさせるように、CPAN.pm の設定を変更できます:
% cpan
cpan> o conf makepl_arg INSTALL_BASE=/mydir/perl
cpan> o conf commit
For Build.PL
-based distributions, use the --install_base option:
Build.PL
-ベースの配布では、--install_base オプションを使ってください:
perl Build.PL --install_base /mydir/perl
You can configure CPAN.pm
to automatically use this option too:
自動的にこのオプションを使うために、CPAN.pm を設定することも出来ます:
% cpan
cpan> o conf mbuild_arg "--install_base /mydir/perl"
cpan> o conf commit
INSTALL_BASE tells these tools to put your modules into /mydir/perl/lib/perl5. See "How do I add a directory to my include path (@INC) at runtime?" for details on how to run your newly installed modules.
INSTALL_BASE はこれらのツールにモジュールを /mydir/perl/lib/perl5 に 置くように伝えます。 新しくインストールしたモジュールを実行する方法についての詳細は "How do I add a directory to my include path (@INC) at runtime?" を 参照してください。
There is one caveat with INSTALL_BASE, though, since it acts differently than the PREFIX and LIB settings that older versions of ExtUtils::MakeMaker
advocated. INSTALL_BASE does not support installing modules for multiple versions of Perl or different architectures under the same directory. You should consider if you really want that , and if you do, use the older PREFIX and LIB settings. See the ExtUtils::Makemaker
documentation for more details.
しかし、INSTALL_BASE には一つの問題点があります; なぜなら、より古いバージョンの ExtUtils::MakeMaker
が推奨していた PREFIX および LIB とは異なった動作をするからです。 INSTALL_BASE は、複数のバージョンの Perl や異なったアーキテクチャに 対して同じディレクトリにモジュールをインストールすることには 対応していません。 もし本当にそれが必要でそうするなら、古い PREFIX と LIB の設定を 考慮するべきです。 さらなる詳細については ExtUtils::Makemaker
の文書を参照してください。
私のプログラムの置いてある場所をモジュール/ライブラリの検索パスに追加するには?¶
(contributed by brian d foy)
(brian d foy によって寄贈されました)
If you know the directory already, you can add it to @INC
as you would for any other directory. You might <use lib> if you know the directory at compile time:
すでにディレクトリが分かっている場合は、それを @INC
に追加できます。 コンパイル時に分かっている場合は、<use lib> が使えます:
use lib $directory;
The trick in this task is to find the directory. Before your script does anything else (such as a chdir
), you can get the current working directory with the Cwd
module, which comes with Perl:
このタスクの秘訣は、ディレクトリを探すことです。 あなたのスクリプトが(chdir
などで)他の場所へ行く前に、Perl に 同梱されている Cwd
モジュールを使って、カレントワーキングディレクトリを 取得できます:
BEGIN {
use Cwd;
our $directory = cwd;
}
use lib $directory;
You can do a similar thing with the value of $0
, which holds the script name. That might hold a relative path, but rel2abs
can turn it into an absolute path. Once you have the
似たようなことは、スクリプト名を記録している $0
でもできます。 これは相対パスかもしれませんが、rel2abs
はこれを絶対パスに変更できます。 以下のようにすると
BEGIN {
use File::Spec::Functions qw(rel2abs);
use File::Basename qw(dirname);
my $path = rel2abs( $0 );
our $directory = dirname( $path );
}
use lib $directory;
The FindBin
module, which comes with Perl, might work. It finds the directory of the currently running script and puts it in $Bin
, which you can then use to construct the right library path:
Perl に同梱されている FindBin
モジュールが働くでしょう。 これは現在実行しているスクリプトのディレクトリを見つけて $Bin
に 設定し、正しいライブラリパスを構築するために使えるようにします:
use FindBin qw($Bin);
実行時にインクルードパス (@INC) にディレクトリを追加するには?¶
Here are the suggested ways of modifying your include path, including environment variables, run-time switches, and in-code statements:
環境変数、実行時スイッチ、コード内の文などを使って、インクルードパスを 変更するためのお薦めの方法を挙げておきます:
- the PERLLIB environment variable
-
(PERLLIB 環境変数)
$ export PERLLIB=/path/to/my/dir $ perl program.pl
- the PERL5LIB environment variable
-
(PERL5LIB 環境変数)
$ export PERL5LIB=/path/to/my/dir $ perl program.pl
- the perl -Idir command line flag
-
(perl の -Idir コマンドラインフラグ)
$ perl -I/path/to/my/dir program.pl
- the use lib pragma:
-
(use lib プラグマ)
use lib "$ENV{HOME}/myown_perllib";
The last is particularly useful because it knows about machine dependent architectures. The lib.pm
pragmatic module was first included with the 5.002 release of Perl.
最後のものが特に便利です。 なぜなら、これはマシン依存のアーキテクチャを知っているからです。 プラグマ的モジュール(pragmatic module) lib.pm
は Perl 5.002 で 最初に導入されました。
socket.ph とは一体何で、それはどこで入手できますか?¶
It's a Perl 4 style file defining values for system networking constants. Sometimes it is built using h2ph
when Perl is installed, but other times it is not. Modern programs use Socket;
instead.
それは Perl 4 スタイルのファイルで、ネットワーク使用のための 値を定義しているものです。 これは Perl がインストールされたときに h2ph
を使って作成されることも ありますが、そうでないときもあります。 最近のやり方では use Socket
を代わりに使用します。
AUTHOR AND COPYRIGHT¶
Copyright (c) 1997-2010 Tom Christiansen, Nathan Torkington, and other authors as noted. All rights reserved.
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 in this file are hereby placed into the public domain. You are permitted and encouraged to use this code in your own programs for fun or for profit as you see fit. A simple comment in the code giving credit would be courteous but is not required.