perlfaq-5.0150039

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

編集

変更履歴

誤訳の報告

原文を表示/隠す

名前
説明
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
    Wx                      CPAN
    Gtk2                    CPAN
    Qt4                     kdebindings4 package

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 モジュールを使ったものです; これは POSIX の termio 構造体の操作を包み隠します。

    # HotKey.pm
    package HotKey;

    use strict;
    use warnings;

    use parent 'Exporter';
    our @EXPORT = qw(cbreak cooked readkey);

    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 (my $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;

    my $terminal = Term::Cap->Tgetent( { OSPEED => 9600 } );
    my $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;

    my $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:

もしこの処理を行うコマンドラインプログラムがあるなら、そのプログラムが出力するものを得るために逆クォートで呼び出して、後でそれを使うこともできます:

    my $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;
    my ($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(my $tty_fh, "+</dev/tty")                     or die "No tty: $!";
    unless (ioctl($tty_fh, &TIOCGWINSZ, $winsize='')) {
        die sprintf "$0: ioctl TIOCGWINSZ (%08x: $!)\n", &TIOCGWINSZ;
    }
    my ($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');
    my $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() and O_RDWR|O_NDELAY|O_NOCTTY from the Fcntl 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 "\015" and "\012". 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 値である "\015" と "\012" とは異なったものになっています。八進表記 ("\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 use select() 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?" を参照してください)。

    my $old_handle = select($dev_fh);
    $| = 1;
    select($old_handle);

You'll also see code that does this without a temporary variable, as in

以下のように、これを一時変数を使わないで行うコードを見るかもしれません:

    select((select($deb_handle), $| = 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_fh->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() or sysread(), 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-arg select() 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 covered 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 opening 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 will wait() 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(1) for specifics) and use pwd_mkdb(8) to install it (see pwd_mkdb(8) for more details).

perl が正しくインストールされていて、かつ、シャドウライブラリがきちんとインストールされていれば、perlfunc で説明されている getpw*() 関数がシャドウパスワードファイルに対する(リードオンリーの) アクセスを提供しています。ファイルを変更するには、新たなシャドウパスワードファイルを作成して (フォーマットはシステム毎に異なります--詳しくは passwd(1) を参照してください)、pwd_mkdb(8) を使ってそれをインストールします (詳細は pwd_mkdb(8) を参照のこと)。

日付や時刻を設定するには?¶

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() をするには? (例外処理)¶

You can use the END block to simulate atexit(). Each package's END block is called when the program or thread ends. See the perlmod manpage for more details about END blocks.

atexit() をシミュレートするのに END ブロックが使えます。それぞれのパッケージの END ブロックは、プログラムやスレッドの終了時に呼び出されます。 END ブロックに関するさらなる詳細については 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 Programming Perl.

Perl の例外処理機構は eval() 演算子です。 setjmp として eval() を、longjmp として die() を使うことができます。これに関する詳細は、シグナルに関するセクション、特に "Signals" in perlipc にあるブロッキング flock() のためのタイムアウトハンドラーと、 Programming Perl の "Signal" の章を参照してください。

If exception handling is all you're interested in, use one of the many CPAN modules that handle exceptions, such as Try::Tiny.

例外処理そのものに興味があるのなら、Try::Tiny のような、例外を扱うための多くの CPAN モジュールの一つを使ってください。

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 the 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 に送ったものを返します。

    my $exit_status   = system("mail-users");
    my $output_string = `ls`;

外部コマンドの STDERR を捕捉するには?¶

There are three basic ways of running external commands:

外部コマンドを実行する基本的なやり方が三つあります:

    system $cmd;        # using system()
    my $output = `$cmd`;        # using backticks (``)
    open (my $pipe_fh, "$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 though Perl emulates fork(), you'll 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:

以下の例のように、シークポインタを保存しておいてそこへ移動します:
```
    my $where = tell($log_fh);
    seek($log_fh, $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
    my $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 といったライブラリを使う Expect を探すのが最善でしょう。

“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(1) 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(1) を参照してください。そのほかもっと良いのは、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(my $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 that 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 .

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

For distributions that use Build.PL:

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 にモジュールをインストールする場所を指定します。

If you want to install modules for your own use, the easiest way might be local::lib, which you can download from CPAN. It sets various installation settings for you, and uses those same settings within your programs.

自分自身が使うためにモジュールをインストールしたいなら、一番簡単な方法は、 CPAN からダウンロードできる local::lib でしょう。これは様々なインストール設定を行い、プログラム中で同じ設定を使います。

If you want more flexibility, you need to configure your CPAN client for your particular situation.

もっと柔軟性がほしいなら、CPAN クライアントを特定の状況に合わせて設定する必要があります。

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 from 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 whether 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);

You can also use local::lib to do much of the same thing. Install modules using local::lib's settings then use the module in your program:

同じことをするのに local::lib も使えます。 local::lib の設定を使ってモジュールをインストールしてから、プログラムでそのモジュールを使います:

     use local::lib; # sets up a local lib at ~/perl5

See the local::lib documentation for more details.

さらなる詳細については local::lib の文書を参照してください。

実行時にインクルードパス (@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 lib pragma:

(lib プラグマ)

    use lib "$ENV{HOME}/myown_perllib";

the local::lib module:

    use local::lib;

    use local::lib "~/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.

最後のものが特に便利です; なぜなら、これはマシン依存のアーキテクチャを知っているからです。プラグマ的モジュール 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 should use use Socket; instead.

それは Perl 4 スタイルのファイルで、ネットワーク使用のための値を定義しているものです。これは Perl がインストールされたときに h2ph を使って作成されることもありますが、そうでないときもあります。最近のプログラムでは代わりに use Socket を使うべきです。

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

名前¶

説明¶

実行しているオペレーティングシステムを見分けるには?¶

なぜ 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¶

なぜ open() はパイプのオープンに失敗したときにエラーを返さないのでしょうか?¶