NAME

perlport - 移植性のある Perl を書く

DESCRIPTION

Perl は多くのオペレーティングシステム上で動作します。 これらのほとんどは一般的にかなりの部分を共有していますが、それぞれ固有の 機能も持っています。

この文書は移植性のある Perl コードの構成要素を発見する助けになるための ものです。 移植性のある形で書こうと決心したら、どこに線が引かれているかを知ることで、 その内側に留まることができます。

ある特定の種類のコンピュータの利点を使うことと、あらゆる範囲の コンピュータの利点を使うことの間にはトレードオフがあります。 当然ながら、より範囲を広げてより多様性のある形にすると、共通の要素が 減っていき、特定のタスクを達成するために操作できる共通の地盤が徐々に 小さくなっていきます。 従って、問題に取りかかるときに、トレードオフのカーブのどの部分を 使うかを考えることは重要です。 特に、コーディングしようとするタスクが移植性に関して完全な一般性が 重要かどうか、またすぐにジョブを終わらせるかどうかを 決定しなければなりません。 残りのことは簡単です。 なぜならあなたが問題にどのようにアプローチしたいとしても Perl は多くの 選択肢を提供するからです。

これを他の方法で見てみると、移植性のあるコードを書くことは通常あなたが 取り得る選択肢を故意に制限します。 当然ながら、これは規律と犠牲が伴います。 おそらく移植性と利便性の積は一定です。 あなたは警告されましたよ。

二つの重要な点に注意してください:

全ての Perl プログラムが移植性がある必要はありません

Unix ツールを互いにくっつけたり、Macintosh アプリケーションのプロトタイプを 作ったり、Windows レジストリを操作するための言語として Perl を 使うべきではないという理由はありません。 プログラムにとって何らかの理由で移植性を目標とすることが無意味なら、 気にしないでください。

ほとんど全ての Perl は既に移植性が あります

移植性のある Perl コードを作るのが難しいという考えに騙されないでください。 そうではありません。 Perl は、異なったプラットフォームで何が利用可能かとこの機能を使うために 利用可能なもの全てとの間のずれを出来るだけ橋渡ししようとします。 従って、ほとんど全ての Perl コードは修正なしにどのマシンでも動作します。 しかし移植性のあるコードを書くにはいくつかの重要な問題があり、この文書は 全体的にそのような問題を扱っています。

一般的なルールを挙げます: プラットフォーム全体で使われて一般的に 処理されるようなタスクに迫るとき、移植性のあるコードを書くことを 考えてください。 その方向で、自分自身の実装の選択肢を多く犠牲にすることはなく、 同時にユーザーに多くのプラットフォームの選択肢を与えることができます。 一方、特定のプラットフォームで固有の機能の利点を使う必要がある場合、 例えば (Unix, Windows, Mac OS, VMS など専用の) システムプログラムのような 場合、プラットフォーム固有のコードを書くことを考えてください。

コードが二つか三つのオペレーティングシステムでだけ動作するときは、 それらの特定のシステムでの違いのみを考慮する必要があります。 重要なことは、どこでコードを実行するかと、決定を熟考することです。

以下の材料は三つの主な章に分割されています: 主な移植性の問題 (問題)、プラットフォーム固有の問題 (プラットフォーム)、 OS によって異なった振る舞いをする perl 組み込み関数 (関数実装) です。

この情報は完全であると考えるべきではありません; これは一部の OS に対する 特異性に関するおそらく一時的な情報を含んでいて、それらのほとんどは常に 進化しているものです。 従って、この材料は永遠に作業中であると考えるべきです (<IMG SRC="yellow_sign.gif" ALT="Under Construction">)。

問題

改行

ほとんどのオペレーティングシステムで、ファイルの行は改行で終端されます。 単に改行として何を使うかが OS によって異なります。 Unix は伝統的に \012 を使い、DOS 風の I/O は \015\012 を使い、 Mac OS は \015 を使います。

Perl は「論理的な」改行を表現するのに \n を使います; 何が論理的かは 使っているプラットフォームに依存しています。 MacPerl では \n は常に \015 を意味します。 DOS 風の perl では、\n は普通 \012 を意味しますが、ファイルを 「テキスト」モードでアクセスすると、STDIO は \015\012 との間で 変換します。 Unix はカノニカルモードの tty で同じことをします。 \015\012 は一般的には CRLF として参照されます。

テキスト行から末尾の改行を切り落とすには、chomp() を使います。 この関数のデフォルト設定は末尾の \n 文字を探すので、移植性のある形で 切り落とします。

バイナリファイル (またはバイナリモードでのテキストファイル) を扱うときには、 chomp() を使う前にファイル形式に適切な値を $/ に明示的に設定してください。

「テキスト」モード変換によって、DOS 的な perl は「テキスト」モードで アクセスするファイルに対する seek と tell の使用に制限があります。 tell で得た位置へ seek する(そして他の方法を使わない)ことに 専念することで、「テキスト」モードでも自由に seek と tell を 使えます。 seek や tell やその他のファイル操作は互換性がないかもしれません。 しかし、ファイルに対して binmode を使うと、普通は任意の値を seek と tell に使っても安全です。

ソケットプログラミングでのよくある誤解は、\n はどこでも \012 に 等しいということです。 一般的なインターネットプロトコルのようなプロトコルを使うとき、 \012 と \015 は明確に記述されていて、論理的な \n と \r (復帰) の値は信頼できません。

    print SOCKET "Hi there, client!\r\n";      # WRONG
    print SOCKET "Hi there, client!\015\012";  # RIGHT

しかし、\015\012 (または \cM\cJ または \x0D\x0A) を使うのは 退屈で見苦しいかもしれませんし、コードの保守に混乱するかもしれません。 そのようなものとして、Socket モジュールは求められていることに対する 正しいものを供給します。

    use Socket qw(:DEFAULT :crlf);
    print SOCKET "Hi there, client!$CRLF"      # RIGHT

ソケットから読み込むとき、デフォルト入力レコード区切り $/ は \n だけれども、堅牢なソケットコードは \012 と \015\012 の どちらも行の末尾として認識することを忘れないでください:

    while (<SOCKET>) {
        # ...
    }

CRLF と LF は両方とも LF で終わっているので、入力レコード区切りを LF に設定して、後から CR を削除できます。 よりよく書くと:

    use Socket qw(:DEFAULT :crlf);
    local($/) = LF;      # not needed if $/ is already \012
    while (<SOCKET>) {
        s/$CR?$LF/\n/;   # not sure if socket uses LF or CRLF, OK
    #   s/\015?\012/\n/; # same thing
    }

この例は -- 例え Unix プラットフォームでも -- 以前のものよりよいものです; なぜなら全ての \015 (\cM) が削除される(そしてこれはとても喜ばしい) からです。

同様に、-- web ページを取得する関数のような -- テキストデータを返す関数は、 まだローカルな改行表現に変換されていないなら、データを返す前に改行を 変換するべき場合もあります。 しばしば 1 行のコードで十分です:

    $data =~ s/\015?\012/\n/g;
    return $data;

これらには混乱があるかもしれません。 以下は ASCII CR と LF 文字の便利なリファレンスです。 これを印刷して財布に貼ることができます。

    LF  eq  \012  eq  \x0A  eq  \cJ  eq  chr(10)  eq  ASCII 10
    CR  eq  \015  eq  \x0D  eq  \cM  eq  chr(13)  eq  ASCII 13
             | Unix | DOS  | Mac  |
        ---------------------------
        \n   |  LF  |  LF  |  CR  |
        \r   |  CR  |  CR  |  LF  |
        \n * |  LF  | CRLF |  CR  |
        \r * |  CR  |  CR  |  LF  |
        ---------------------------
        * text-mode STDIO

Unix の列は、カノニカルモードで(tty のような)シリアルインターフェースに アクセスしているのではないことを仮定しています。 もしそうなら、入力の CR は "\n" になり、出力の "\n" は CRLF になります。

これらは単に Perl でのもっとも一般的な \n と \r の定義です。 他のものもあり得ます。 例えば、z/OS (OS/390) や OS/400 (ILE を使っている場合; PASE は ASCII ベース) のような EBCDIC 実装では、上述の資料は "Unix" と同様ですが、 コード番号が変更されます:

    LF  eq  \025  eq  \x15  eq  \cU  eq  chr(21)  eq  CP-1047 21
    LF  eq  \045  eq  \x25  eq           chr(37)  eq  CP-0037 37
    CR  eq  \015  eq  \x0D  eq  \cM  eq  chr(13)  eq  CP-1047 13
    CR  eq  \015  eq  \x0D  eq  \cM  eq  chr(13)  eq  CP-0037 13
             | z/OS | OS/400 |
        ----------------------
        \n   |  LF  |  LF    |
        \r   |  CR  |  CR    |
        \n * |  LF  |  LF    |
        \r * |  CR  |  CR    |
        ----------------------
        * text-mode STDIO

数値のエンディアンと幅

CPU が異なると、整数と浮動小数点数の順序 (エンディアン (endianness) と 呼ばれます) と幅 (最近ではほとんど 32 ビットと 64 ビットです) が異なります。 これは、ある CPU アーキテクチャから他のものへ数値をバイナリ形式で、 普通はネットワーク接続経由で「ライブ」で、またはディスクファイルや テープのような二次ストレージに保管することで移そうとしたときに 影響します。

保管の順序が章とすると値が完全におかしくなります。 リトルエンディアンのホスト (Intel, VAX) が 0x12345678 (10 進数では 305419896) を保管すると、ビッグエンディアンのホスト (Motorola, Sparc, PA) は これを 0x78563412 (10 進数では 2018915346) として読み込みます。 Alpha と MIPS はどちらもあり得ます: Digital/Compaq はこれを リトルエンティアンモードで使います; SGI/Cray はこれを ビッグエンディアンモードで使います。 ネットワーク(ソケット)接続でこの問題を避けるには、pack と unpack の 「ネットワーク」順序フォーマットである n および N を使ってください。 これらは移植性があることを保証します。

perl 5.9.2 から、ビッグエンディアンとリトルエンディアンにバイト順を 強制するための > と < の修飾子も使えます。 これは例えば、符号付き整数や 64 ビット整数を保管したいときに有用です。

次のように、ネイティブな形式で pack されたデータ構造を unpack することで プラットフォームのエンディアンを調べることができます:

    print unpack("h*", pack("s2", 1, 2)), "\n";
    # '10002000' on e.g. Intel x86 or Alpha 21064 in little-endian mode
    # '00100020' on e.g. Motorola 68040

エンディアンアーキテクチャを区別する必要があるなら、以下のような変数の どちらかを使えます:

    $is_big_endian   = unpack("h*", pack("s", 1)) =~ /01/;
    $is_little_endian = unpack("h*", pack("s", 1)) =~ /^1/;

幅の違いは同じエンディアンのプラットフォームの間でも切り詰めを 引き起こすことがあります。 幅がより短い側のプラットフォームは数値の上位部分を失います。 生のバイナリ数値を転送したり保管したりしないようにする以外に、この問題への よい解決法はありません。

これらの問題は二つの方法で避けることが出来ます。 数値を常に生のバイナリではなくテキスト形式で転送して保管するか、 (Perl 5.005 から標準配布に含まれている) Data::Dumper や (perl 5.8 から 含まれている) Storable のようなモジュールを使うことを考慮します。 全てのデータをテキストで扱うことは問題をかなり単純化します。

v-文字列は v2147483647 (0x7FFFFFFF) 以下でのみ移植性があります; これは EBCDIC、より正確には UTF-EBCDIC よりも遙かに遠いです。

ファイルとファイルシステム

最近のほとんどのプラットフォームではファイルの構造は階層的です。 従って、全てのプラットフォームがシステム中のファイルをユニークに 識別するための「パス」記法に対応していると仮定することは合理的に安全です。 パスが実際にどのように書かれるかはかなり異なります。

似てはいるものの、ファイルパスの指定方法は Unix, Windows, Mac OS, OS/2, VMS, VOS, RISC OS そしておそらくその他で 異なります。 例えば、Unix は一つのルートディレクトリというエレガントな考え方を持つ 数少ない OS の一つです。

DOS, OS/2, VMS, VOS, Windows は / をパス区切りとして、(複数の ルートディレクトリや、NIL: や LPT: のような様々な「ルートでない」 デバイスファイルといった)独自の風変わりな方法で Unix と似たように 動作します。

Mac OS はパス区切りに / ではなく : を使います。

ファイルシステムはハードリンク (link) やシンボリックリンク (symlink, readlink, lstat) に対応していないかもしれません。

ファイルシステムはアクセスタイムスタンプや変更タイムスタンプに 対応していないかもしれません (つまり移植性のあるタイムスタンプは 変更タイムスタンプだけです); またタイムスタンプは 1 秒単位では ないかもしれません (例えば、FAT ファイルシステムは時刻の単位は 2 秒単位です)。

「inode 変更タイムスタンプ」 (-C ファイルテスト) は (UNIX 以外では) 実際には「作成タイムスタンプ」かもしれません。

VOS perl は / をパス区切りとして Unix ファイル名をエミュレートできます。 ネイティブなパス名文字である大なり、小なり、シャープ、パーセントは常に 受け入れられます。

RISC OS perl は / をパス区切りとして Unix ファイル名をエミュレート するか、ネイティブのままで . をパス区切り、: をファイルシステムと ディスクの名前として使えます。

UNIX のファイルシステムアクセスの意味を仮定しないで下さい: 読み込み、 書き込み、実行のどれもです; たとえあったとしても、その意味論 (例えばディレクトリに対して r, w, x が何をするか) は UNIX のものです。 様々な UNIX/POSIX 互換層は普通 chmod() のようなものが動作するための インターフェースとなっていますが、ときどき単にいいマッピングが ないこともあります。

もしこれら全てが怯えさせるものであるなら、恐れないでください(あー、多分 ほんの少しだけ恐れてください)。 助けになるモジュールがあります。 File::Spec モジュールはプログラムがどのプラットフォームで動作していても 「正しいこと」をします。

    use File::Spec::Functions;
    chdir(updir());        # go up one directory
    $file = catfile(curdir(), 'temp', 'file.txt');
    # on Unix and Win32, './temp/file.txt'
    # on Mac OS, ':temp:file.txt'
    # on VMS, '[.temp]file.txt'

File::Spec はバージョン 5.004_05 から標準配布で利用可能です。 File::Spec::Functions は File::Spec 0.7 以降のみにあり、一部のバージョンの perl はバージョン 0.6 を含んでいます。 File::Spec が 0.7 以降に更新されていないなら、File::Spec の オブジェクト指向インターフェースを使わなければなりません (あるいは File::Spec を更新しなければなりません)。

一般的に、製品コードはファイルパスをハードコーディングするべきでは ありません。 ユーザーが指定できるようにするか、設定ファイルから読み込む方がよいです; ファイルパスの文法はマシンによって異なることを忘れないでください。

これは、しばしば / がサブディレクトリのパス区切りと仮定されている Makefile やテストスイートのようなスクリプトで特に注意が必要です。

もう一つの有用なものは標準配布に含まれている File::Basename で、これは パス名をベースファイル名、ディレクトリのフルパス、ファイルの拡張子に 分解します。

単一のプラットフォームでさえ(Unix を単一のプラットフォームと呼ぶなら)、 /etc/passwd, /etc/sendmail.conf, /etc/resolv.conf あるいは /tmp/ でさえ、特定のシステム固有のファイルやディレクトリの存在や その内容を当てにできないことを忘れないでください。 例えば、/etc/passwd は存在するかもしれませんが、システムがある種の 強化されたセキュリティを使っているために、暗号化されたパスワードを 含んでいないかもしれません。 あるいは、NIS を使っているために、全てのアカウントを 含んでいないかもしれません。 コードがこのようなファイルに依存する必要がある場合、コードの文書に ファイルの説明とその形式を含めて、ユーザーがファイルのデフォルトの位置を 簡単に上書きできるようにします。

テキストファイルが改行で終わっていると仮定しないでください。 そうあるべきですが、人は忘れます。

test.pl と Test.pl のような、大文字と小文字が違うだけの名前の二つの ファイルやディレクトリを作らないでください; 多くのプラットフォームは 大文字小文字を無視する(あるいは少なくとも大文字小文字に寛容な) ファイル名を持つからです。 また、最大限の互換性のため、起きるかも知れない厄介事のために、 (. 以外の)非単語文字を使わないようにして、8.3 の規約を維持してください。

同様に、AutoSplit モジュールを使う場合、関数の 8.3 の命名と大文字小文字を 無視する規約を維持するようにしてください; あるいは、少なくとも、 結果のファイルが最初の 8 文字が(大文字小文字を無視して)ユニークに なるようにしてください。

ファイル名の空白はほとんどのシステムで許容されますが、全てではなく、 許容しているシステムでも、そのような空白によって混乱するユーティリティも あります。

多くのシステム (DOS, VMS ODS-2) はファイル名に二つ以上の . を 使えません。

> がファイル名の最初の文字ではないと仮定しないでください。 ユーザーがパイプで開けるようにしたいのでない限り、読み込みのためにファイルを 開くときには常に明示的に < を使うか、もっとよいのは、3 引数版の open を使ってください。

    open(FILE, '<', $existing_file) or die $!;

もしファイル名におかしな文字が使われているかも知れないなら、 open ではなく sysopen を使って開くのがもっとも安全です。 open はマジカルで、>, <, | のような文字を 変換することがあり、これは間違ったことかもしれません。 (しかし、時々は、これは正しいことです。) 3 引数形式の open も予想していない状況でこの変換から守る助けになります。

: をファイル名の一部として使わないでください; 多くのシステムがこれを 同時の意味で使っているからです (Mac OS Classic はパス名要素を分割するために、 多くのネットワークスキームとユーティリティではノード名とパス名を 分割するために、など)。 同じ理由で、@, ;, | も避けてください。

パス名の先頭の二つのスラッシュ // を一つに圧縮できると 仮定しないでください: ある種のネットワーキングとクラスタリングの ファイルシステムはこれに対して特別な意味論を持ちます。 オペレーティングシステムに任せてください。

ANSI C で定義されている、移植性のあるファイル名の文字 は:

 a b c d e f g h i j k l m n o p q r t u v w x y z
 A B C D E F G H I J K L M N O P Q R T U V W X Y Z
 0 1 2 3 4 5 6 7 8 9
 . _ -

かつ "-" は最初の文字には使えません。 もし超完全にしたいなら、大文字小文字は無視して、8.3 命名規約に従います (全てのファイルとディレクトリは、名前を小文字にして、(もしあれば) . の 前の 8 文字と (もしあれば) . の後の 3 文字に切り詰めたときに、 ディレクトリ内でユニークである必要があります)。 (そしてディレクトリ名に . を使わないでください。)

システムの相互作用

全てのプラットフォームがコマンドラインを提供しているわけではありません。 これらは普通ユーザーとの相互作用にグラフィカルユーザーインターフェース (GUI) に基本的に依存しています。 コマンドラインインターフェースを要求するプログラムはどこでも 動作するわけではありません。 これはおそらくプログラムを扱うユーザーの問題なので、心配して遅くまで 遅くまで起きていないでください。

一部のプラットフォームはシステムによって開かれているファイルを削除または リネームできません; この制限はファイル権限や所有者のような ファイルシステムのメタ情報の変更にも適用されることもあります。 ファイルに対する作業が終わったら、close することを忘れないでください。 開いているファイルに対して unlink または rename しないでください。 すでに tie されていたり開かれていたりするファイルに対して tie や open をしないで下さい; まず untie または close してください。

同じファイルを同時に 2 回以上書き込みのために開いてはいけません; 一部のオペレーティングシステムはそのようなファイルに排他的ロックを掛けます。

ディレクトリへの書き込み/修正権限があれば、そのディレクトリにある ファイル/ディレクトリを追加または削除できると仮定しないでください。 これはファイルシステム依存です: そのファイル/ディレクトリ自身の 書き込み/修正権限も(あるいはそれだけが)必要なファイルシステムもあります。 一部のファイルシステム (AFS, DFS) では、ディレクトリ要素の追加/削除権限は 完全に別の権限です。

1 回の unlink で完全にファイルを取り除けると仮定しないでください: 一部のファイルシステム (もっとも顕著なものは VMS) はバージョン管理された ファイルシステムを持ち、unlink() は単に最新のものだけを削除します (デフォルトではネイティブなツールも単に最新のバージョンを削除するので、 全てのバージョンは削除しません)。 あるファイルの全てのバージョンを削除するための移植性のある慣用句は:

    1 while unlink "file";

これは (保護されている、存在しない、など) 何らかの理由でファイルが 削除できないときに終了します。

特定の環境変数が %ENV にあるということを計算に入れないでください。 %ENV のエントリが大文字小文字を認識するかや、大文字小文字が 保存されるかすらも計算に入れないでください。 %ENV をクリアするために %ENV = (); としないでください; もし 本当にそうする必要があるなら、$^O ne 'VMS' という条件付きで 行ってください; VMS では %ENV テーブルはプロセス単位のキー/値文字列 テーブル以上のものだからです。

VMS では、%ENV ハッシュの一部のエントリは、キーがまだ存在していなければ、 読み込みに使われたときに動的に作成されます。 $ENV{HOME}, $ENV{TERM}, $ENV{HOME}, and $ENV{USER} の値は 動的に作成されると知られています。 動的に作成される具体的な名前は VMS の C ライブラリのバージョンによって 異なり、文書化されているものよりもたくさんあるかもしれません。

VMS のデフォルトでは、%ENV ハッシュへの変更は、プロセスが終了した後に 永続化します。 これは意図していない問題を引き起こすかもしれません。

シグナルや %SIG について何も当てにしないで下さい。

ファイル名のグロブを当てにしないで下さい。 代わりに opendir, readdir, closedir を使ってください。

プログラム単位の環境変数や、プログラム単位のカレントディレクトリを 当てにしないで下さい。

$! の特定の値を計算に入れないでください; 数値でも、特に文字列値でも です -- ユーザーは自分の言語へ翻訳するためにエラーメッセージを引き起こす ロケールを変更するかもしれません。 もし POSIX 的な環境を信用できるなら、ENOENT のような、Errno モジュールで 定義されているシンボルを移植性を持って使えます。 そして、システムコールが失敗した直後以外では $! の値は全く 信用しないでください。

コマンド名かファイルパス名か

system や exec でコマンドやプログラムを起動するために使われた名前が、 そのコマンドやプログラムの実行可能コードを保持しているファイルの存在の テストにも使えると仮定しないでください。 1 番目に、多くのシステムはシェルや OS に組み込まれている「内部」コマンドを 持ち、これらのコマンドは起動できますが、対応するファイルはありません。 2 番目に、一部のオペレーティングシステム(例えば Cygwin, DJGPP, OS/2, VOS) は 実行ファイルに拡張子が必要です; これらの拡張子は一般的にコマンド名として ゆるされていますが要求されてはいません。 従って、"perl" のようなコマンドは OS に依存して、"perl", "perl.exe", "perl.pm" のようなファイルとして存在しているかもしれません。 The variable in the Config モジュールの変数 "_exe" は、(もしあれば)実行形式の拡張子を保持します。 3 番目に、VMS 版はそれ以上の処理が不要なように慎重に $^X と $Config{perlpath} を設定します。 これは、以下に示す正規表現のマッチングがそれから VMS ファイル名に あるかもしれない末尾のバージョン番号を扱う必要があるからです。

$^X をファイルパス名に変換するとき、以下のように、様々な オペレーティングシステムの可能性の要求を考慮してください:

  use Config;
  $thisperl = $^X;
  if ($^O ne 'VMS')
     {$thisperl .= $Config{_exe} unless $thisperl =~ m/$Config{_exe}$/i;}

$Config{perlpath} をファイルのパス名に変換するには、例えば:

  use Config;
  $thisperl = $Config{perlpath};
  if ($^O ne 'VMS')
     {$thisperl .= $Config{_exe} unless $thisperl =~ m/$Config{_exe}$/i;}

ネットワーク

公共のインターネットに届くことを仮定しないでください。

ファイアウォールを通って公共のインターネットへ出る道が 一つだけあるということを仮定しないでください。

ポート 80 やいくつかのウェブプロキシを以外で、外側の世界に届くことを 仮定しないでください。 ftp は多くのファイアウォールでブロックされます。

ローカル SMTP ポートに接続することで e メールを送信できると 仮定しないでください。

'localhost' という名前で自分自身やその他のノードに届くと 仮定しないでください。 同じことは '127.0.0.1' にも言えます。 両方を試す必要があります。

ホストに 1 枚だけネットワークカードがあるとか、複数の仮想 IP アドレスを 割り当てられないと仮定しないでください。

特定のネットワークデバイス名を仮定しないでください。

特定の ioctl() が動作することを仮定しないでください。

ホストに ping して結果が受け取れると仮定しないでください。

特定のポート (サービス) が返答すると仮定しないでください。

Sys::Hostname (またはその他の API やコマンド) が完全修飾ホスト名か 修飾されないホスト名のどちらかを返すと仮定しないでください: これら全ては システムがどのように設定されているかに依存します。 また、DHCP や NAT のことも忘れないでください -- 受け取るホスト名は全く 有用ではないかもしれません。

上述した全ての「べからず」は怯えさせるものかもしれません; そしてその 通りです -- しかし鍵は、望んでいる特定のネットワークサービスに 到達できないときに、適切にデグレードすることです。 croak やハングアップではとてもプロの仕事には見えません。

プロセス間通信(IPC)

一般的に、移植性を持たせるコード内でシステムに直接アクセスしないでください。 つまり、system, exec, fork, pipe, ``, qx//, open での | その他 perl ハッカーが価値があると思うものです。

外部プロセスを起動するコマンドは一般的にほとんどのプラットフォームで 対応しています(しかしその多くは fork に対応していません)。 これらを使うときの問題は何を起動するかということから発生します。 外部ツールはプラットフォームが異なればしばしば異なった名前となり、 同じ場所で利用可能ではないかもしれず、異なった引数を受け取るかもしれず、 異なった動作をするかもしれず、しばしば結果をプラットフォームに依存した形で 表現します。 従って、一貫した結果を生成するために、ほとんどそのようなものに 依存しないようにするべきです。 (再び、netstat -a を呼び出すなら、おそらく Unix と CP/M の両方で 呼び出すことを想定していないでしょう。)

特に一般的な Perl コードの一つは sendmail へのパイプを開くことです:

    open(MAIL, '|/usr/lib/sendmail -t') 
        or die "cannot fork sendmail: $!";

sendmail が利用可能であることが分かっているならシステム プログラミングとしてうまく動きます。 しかし多くの非 Unix システムや、Unix でも sendmail が インストールされていないシステムではうまく動きません。 移植性のある解法が必要なら、CPAN にあるこれを扱うための様々な ディストリビューションを参照してください。 Mail::Mailer および MailTools の Mail::Send は一般的に使われ、mail、 sendmail、メール転送エージェントが利用できないなら (Net::SMTP 経由で) SMTP 直接を含むいくつかのメール送信メソッドを提供します。 Mail::Sendmail は単純で、プラットフォーム独立なメール送信を提供する 単体のモジュールです。

Unix System V IPC (msg*(), sem*(), shm*()) は Unix プラットフォームでさえも全てで利用できるわけではありません。

IPv4 アドレスを表現するために pack("N", 10, 20, 30, 40) の生の結果や (v10.20.30.40 のような)生のv-文字列を使わないでください: どちらの 形式も単に 4 バイトをネットワーク順序で pack しています。 これが(ソケットコードが内部で使う) C 言語の in_addr 構造体と 同じであることは保証されていません。 移植性を持たせるためには、inet_aton(), inet_ntoa(), sockaddr_in() のような、Socket エクステンションのルーチンを 使ってください。

移植性のあるコードのための経験的な法則は: 全て移植性のある Perl でするか、 モジュールを使ってください (これは内部でプラットフォーム依存の実装を しているかもしれませんが、一般的なインターフェースを晒しています)。

外部サブルーチン(XS)

XS コードは普通どのプラットフォームでも動作するように作られていますが、 依存ライブラリ、ヘッダファイルなどが利用可能でなかったり移植性がなかったり、 XS コード自身が (Perl コードがそうであるかもしれないように) プラットフォーム依存かもしれません。 ライブラリとヘッダに移植性があるなら、XS コードも移植性があると 考えるのは普通合理的です。

XS コードを書くときには違った種類の移植性の問題が発生します: エンドユーザーのシステムで C コンパイラが利用できるかです。 C はそれ自身の移植性の問題があり、XS コードはそれらのいくつかを晒します。 ピュア Perl で書くことは移植性を達成するより簡単な方法です。

標準モジュール

一般的に、標準モジュールはどのプラットフォームでも動きます。 注目するべき例外は CPAN モジュール (今のところ利用可能でないかもしれない 外部プログラムと接続します)、(ExtUtils::MM_VMS のような) プラットフォーム固有のモジュール、DBM モジュールです。

全てのプラットフォームで利用可能な DBM モジュールはありません。 SDBM_File とその他は一般的に全ての Unix と DOS 風版で利用可能ですが、 MacPerl では利用できず、NBDM_File と DB_File のみが利用可能です。

いい知らせは、少なくとも何らかの DBM モジュールは利用可能なはずで、 AnyDBM_File は見付かったどれかのモジュールを使います。 もちろん、任意の DBM モジュールで動作させるために、コードはかなり厳密で、 最大公約数的機能に限定されます(例えば、各レコードは 1K を超えられません)。 さらなる詳細については AnyDBM_File を参照してください。

時刻と日付

カレンダー日付と時刻のシステムでの記法は大きく異なった方法で 制御されています。 タイムゾーンが $ENV{TZ} に保管されていると仮定しないでください; また例え保管されていても、この変数でタイムゾーンを制御できると 仮定しないでください。 3 文字タイムゾーン略称について何の仮定もしないで下さい (例えば MST は Mountain Standard Time かもしれませんが、Moscow Standard Time としても 知られています)。 タイムゾーンを使う必要があるなら、UTC からの正確な分数や POSIX タイムゾーン形式のような、曖昧さのない形式で記述してしてください。

紀元が 1970 年 1 月 1 日 00:00:00 に開始されると仮定しないでください; なぜならこれは OS と実装に依存するからです。 曖昧さのない表現で日付を保管した方が良いです。 ISO 8601 標準は日付の形式として YYYY-MM-DD を、あるいは YYYY-MM-DDTHH-MM-SS (リテラルな "T" は日付と時刻を分けています) を 定義しています。 どうか 02/03/04 という日付の意味を推測させるのではなく、ISO 8601 を 使ってください。 ISO 8601 はそのままうまくソートもできます。 ("1987-12-18" のような) テキスト表現は Date::Parse のようなモジュールを 使って簡単に OS 固有の値に変換できます。 localtime で返されるような値の配列は、Time::Local を使って OS 固有の 表現に変換できます。

時刻と日付のモジュールのテストのような、特定の時刻を計算するときには、 紀元からのオフセットを計算するのが適切でしょう。

    require Time::Local;
    $offset = Time::Local::timegm(0, 0, 0, 1, 0, 70);

Unix での $offset の値は 0 ですが、Mac OS では大きな数になります。 それから、$offset は任意のシステムでの適切な値を得るために Unix time に加えられます。

(少なくとも) Windows では、gmtime や localtime に負数を 渡すべきではありません。

文字集合と文字エンコーディング

文字集合について仮定できることはほとんどありません。

文字の数値 (ord, chr) について仮定できることはありません。 (\xHH-\xHH のような) 明示的な符号位置の範囲は使わないでください; 例えば [:print:] のようなシンボリックな文字クラスを使ってください。

英字が(数値的な意味で)連続してエンコードされると仮定しないでください。 隙間があるかもしれません。

文字の順序について何も仮定しないでください。 小文字は大文字の前かもしれませんし後かもしれません; 小文字と大文字が交互に 来るために、"a" と "A" の両方が "b" の前かもしれません; アクセント文字や その他の国際文字は交互に来るかも知れないので ä は "b" の 前かもしれません。

国際化

POSIX (比較的大きい仮定) を仮定するなら、perllocale から POSIX ロケールシステムについて多くを読めます。 ロケールシステムは少なくとも物事をもう少し移植性のある形にしようとする、 あるいは少なくとも非英語ユーザにとってより便利で母国語に親しくするものです。 このシステムは文字集合とエンコーディング、日付と時刻の形式 -- 他のものに 混じって -- に影響を与えます。

もし本当に国際化したいなら、Unicode を考慮するべきです。 さらなる情報については perluniintro と perlunicode を 参照してください。

非 ASCII バイト (0x00..0x7f の範囲外のバイト) を「ソースコード」に 使いたいなら、移植性のために、そのバイトが何であるかを明示的にする必要が あります。 誰かが例えばそのコードを UTF-8 ロケールで使うかもしれず、その場合 ランダムなネイティブのバイトは不正となります ("Malformed UTF-8 ...")。 これは例えば 0x7f を超える ISO 8859-1 のバイトを文字列に組み込むと あとで問題を引き起こすかもしれないということです。 そのバイトがネイティブな 8 ビットバイトなら、bytes プラグマを使えます。 そのバイトが文字列にある(正規表現はおかしな文字列になります)なら、 そのバイトをそのまま組み込む代わりに \xHH 表記もしばしば使われます。 (コードを UTF-8 で書きたいなら、utf8 が使えます。) bytes と utf8 のプラグマは Perl 5.6.0 から利用可能です。

システムリソース

あなたのコードが仮想メモリについて厳しく制限された(あるいは存在しない!) システムで動作することになっているなら、特に 以下のような無駄な構造を 避けたいです:

    # NOTE: this is no longer "bad" in perl5.005
    for (0..10000000) {}                       # bad
    for (my $x = 0; $x <= 10000000; ++$x) {}   # good
    @lines = <VERY_LARGE_FILE>;                # bad
    while (<FILE>) {$file .= $_}               # sometimes bad
    $file = join('', <FILE>);                  # better

最後の二つの構造はほとんどの人々にとって直観的ではないかもしれません。 一番目は徐々に文字列が大きくなり、二番目は一度に大きなメモリの塊を 割り当てます。 システムによっては、二番目の方が一番目よりも効率的です。

セキュリティ

ほとんどのマルチユーザプラットフォームでは(普通はファイルシステムで 実装された)基本的なレベルのセキュリティを提供しています。 しかし、一部は -- 残念ながら -- そうではありません。 従ってユーザー ID、"home" ディレクトリ、あるいはログインしているかどうか という概念すら多くのプラットフォームでは認識できないかもしれません。 セキュリティを意識したプログラムを書くなら、どの種類のシステムで 実行されるかを知るのが普通は最良です; これによって明示的にその プラットフォーム(またはプラットフォームの種類)のためのコードを書けます。

UNIX のファイルシステムアクセス意味論を仮定しないでください: オペレーティングシステムやファイルシステムは通常の rwx よりも豊富な 機能を持つ ACL システムを使っているかもしれません。 rwx が存在したとしても、意味は違うかもしれません。

(セキュリティの面からは、何かをしようとする前に権限をテストするのは そもそもばかげています: そうしようとすると、潜在的な競合条件があります -- 権限チェックと実際の操作の間に誰かまたは何かが権限を変えるかもしれません。 単に操作を試してください。)

UNIX のユーザーとグループの意味論を仮定しないでください: 特に、ユーザー (あるいはグループ)を切り替えるのに $< と $> (または $( と $)) が動作すると想定しないでください。

set-uid と set-gid の動作を仮定しないでください。 (そしてそうしたとしても、二度考えてください: set-uid と set-gid はセキュリティの虫の缶詰として知られています。)

スタイル

プラットフォーム固有のコードを書く必要がある時には、プラットフォーム固有の コードを 1 箇所に集めて、他のプラットフォームへの移植をより容易にすることを 考慮してください。 プラットフォーム で記述されているように、プラットフォームを識別するために Config モジュールと特殊変数 $^O を使ってください。

モジュールやプログラムと共に提供するテストには注意してください。 モジュールのコードは完全に移植性があるかも知れませんが、 テストはそうではないかもしれません。 これは、テストの助けとするために他のプロセスを起動したり外部のプログラムを 呼び出したりしたり、テストが(上述したように)ファイルシステムやパスについて ある種の仮定をしたときにしばしば起こります。 システムコールに失敗したあとの $! のような、エラーの特定の出力形式に 依存しないように注意してください。 出力として表示する以外のことに $! を使うことは疑問があります(しかし エラー値について十分な移植性のあるテストを刷るための Errno モジュールを 参照してください)。 一部のプラットフォームはある種の出力形式を想定していて、それらの プラットフォームの Perl はそれに応じて調整します。 もっとも厳密に言えば、エラー値をテストするときに正規表現を 使わないでください。

CPAN Testers

CPAN にアップロードされたモジュールは色々なプラットフォームで 様々なボランティアによってテストされます。 これらの CPAN testers は新しくアップロードされることにメールによって 通知され、PASS, FAIL, NA (このプラットフォームでは不適切), UNKNOWN (不明) のいずれかを、関連する情報と共に返信します。

テストの目的は二つあります: 一つ目は、他のプラットフォームのテストが ないことによって突然現れるコードの問題を開発者が修正することを 助けるためです; 二つ目は、あるモジュールがあるプラットフォームで 動作するかどうかの情報をユーザーに提供することです。

以下も参照してください:

プラットフォーム

バージョン 5.002 から、Perl は $^O 変数がビルドされたオペレーティング システムを示すような形でビルドされます。 これは、use Config して $Config{osname} の値を調べる必要が ないようにすることで高速化を助けています。 もちろんシステムからもっと詳細な情報を得るなら、%Config を 見ることが確実にお勧めです。

しかし、%Config はコンパイル時にビルドされるので、常に 信頼するというわけにはいきません。 perl がある場所でビルドされ、それから別の場所に移されると、いくつかの 値は間違ったものになるかもしれません。 値は後から修正することすらできます。

Unix

Perl は驚くほど色々な Unix と Unix 風プラットフォームで動作します (例えば ソースコードキットの hints/ ディレクトリのほとんどのファイルを 参照してください)。 これらのシステムのほとんどでは、$^O の値は (従って $Config{'osname'} の値も)、シェルプロンプトから uname -a (または 似たようなコマンド) で返された文字列の最初のフィールドから句読点を 取り除いて小文字にしたものか、カーネルやヘッダファイルのようなユニークな 名前の付いたファイルの存在をファイルシステムで調べることによって 決定されます。 例えば、以下はより有名な Unix 風システムのいくつかです:

    uname         $^O        $Config{'archname'}
    --------------------------------------------
    AIX           aix        aix
    BSD/OS        bsdos      i386-bsdos
    Darwin        darwin     darwin
    dgux          dgux       AViiON-dgux
    DYNIX/ptx     dynixptx   i386-dynixptx
    FreeBSD       freebsd    freebsd-i386    
    Haiku         haiku      BePC-haiku
    Linux         linux      arm-linux
    Linux         linux      i386-linux
    Linux         linux      i586-linux
    Linux         linux      ppc-linux
    HP-UX         hpux       PA-RISC1.1
    IRIX          irix       irix
    Mac OS X      darwin     darwin
    MachTen PPC   machten    powerpc-machten
    NeXT 3        next       next-fat
    NeXT 4        next       OPENSTEP-Mach
    openbsd       openbsd    i386-openbsd
    OSF1          dec_osf    alpha-dec_osf
    reliantunix-n svr4       RM400-svr4
    SCO_SV        sco_sv     i386-sco_sv
    SINIX-N       svr4       RM400-svr4
    sn4609        unicos     CRAY_C90-unicos
    sn6521        unicosmk   t3e-unicosmk
    sn9617        unicos     CRAY_J90-unicos
    SunOS         solaris    sun4-solaris
    SunOS         solaris    i86pc-solaris
    SunOS4        sunos      sun4-sunos

$Config{archname} の値はハードウェアアーキテクチャに依存しているため、 $^O の値よりも様々な値になります。

DOS とその派生

Perl は昔から Intel 形式のマイクロコンピュータで動作する PC-DOS, MS-DOS, OS/2 のようなシステムと、あなたが指摘できるようなほとんど全ての Windows プラットフォーム(もし Windows CE を含めるなら、これは除きます)に 移植されてきました。 COMMAND.COM や CMD.EXE 形式のシェルになれているユーザーは、 以下のようなファイル指定に少しずつ違いがあることに気がつくはずです:

    $filespec0 = "c:/foo/bar/file.txt";
    $filespec1 = "c:\\foo\\bar\\file.txt";
    $filespec2 = 'c:\foo\bar\file.txt';
    $filespec3 = 'c:\\foo\\bar\\file.txt';

システムコールはパス区切りとして / または \ のどちらかを受け付けます。 しかし、古い DOS のコマンドラインユーティリティは / をオプションの 接頭辞として扱うので、ファイル名に / が含まれていると混乱するかも しれません。 外部プログラムを呼び出すことを除いて、/ はとてもうまく動作し、おそらく よりよいです; なぜなら一般的な使用法でより一貫性があって、何が バックスラッシュで何が層でないかを覚えるという問題を避けられます。

DOS FAT ファイルシステムは "8.3" 形式のファイル名にのみ対応しています。 「大文字小文字を無視するが、保存する」HPFS (OS/2) と NTFS (NT) ファイルシステムでは readdir のような関数から返されたり、open や opendir のような関数で使う大文字小文字に注意する必要が あるかもしれません。

DOS はまた、AUX, PRN, NUL, CON, COM1, LPT1, LPT2 のようないくつかの ファイル名を特別に扱います。 残念ながら、ときどきこれらのファイル名は明示的なディレクトリ接頭辞に 含んでいても動作しません。 コードに DOS とその派生で移植性があるようにするには、これらのファイル名を 避けるのが最良です。 残念ながら、これら全てを知るのは難しいです。

これらのオペレーティングシステムのユーザーは、スクリプトのラッパーとして pl2bat.bat や pl2cmd のようなスクリプトを使いたいかもしれません。

ファイルから読み書きするとき、改行 (\n) は STDIO によって \015\012 に 変換されます(改行 を参照してください)。 binmode(FILEHANDLE) は、このファイルハンドルに対して \n を \012 として変換されます。 これはその他のシステムでは何もしないので、バイナリデータを扱う クロスプラットフォームコードでは binmode を使うべきです。 これは、予めデータがバイナリであることが分かっていることを仮定しています。 汎用プログラムはデータについて何も仮定しないべきです。

様々な DOS 的な perl での $^O 変数と $Config{archname} の値は 以下の通りです:

     OS            $^O      $Config{archname}   ID    Version
     --------------------------------------------------------
     MS-DOS        dos        ?                 
     PC-DOS        dos        ?                 
     OS/2          os2        ?
     Windows 3.1   ?          ?                 0      3 01
     Windows 95    MSWin32    MSWin32-x86       1      4 00
     Windows 98    MSWin32    MSWin32-x86       1      4 10
     Windows ME    MSWin32    MSWin32-x86       1      ?
     Windows NT    MSWin32    MSWin32-x86       2      4 xx
     Windows NT    MSWin32    MSWin32-ALPHA     2      4 xx
     Windows NT    MSWin32    MSWin32-ppc       2      4 xx
     Windows 2000  MSWin32    MSWin32-x86       2      5 00
     Windows XP    MSWin32    MSWin32-x86       2      5 01
     Windows 2003  MSWin32    MSWin32-x86       2      5 02
     Windows CE    MSWin32    ?                 3           
     Cygwin        cygwin     cygwin

様々な MSWin32 Perl は、Win32::GetOSVersion() から返されるリストの 5 番目の 要素の値を使って動作している OS を区別できます。 例えば:

    if ($^O eq 'MSWin32') {
        my @os_version_info = Win32::GetOSVersion();
        print +('3.1','95','NT')[$os_version_info[4]],"\n";
    }

また Win32::IsWinNT() と Win32::IsWin95() もあります; perldoc Win32 を 試してみてください; そして libwin32 0.19 (コア Perl 配布の一部では ありません) からは Win32::GetOSName() があります。 とても移植性のある POSIX::uname() も動作します:

    c:\> perl -MPOSIX -we "print join '|', uname"
    Windows NT|moonru|5.0|Build 2195 (Service Pack 2)|x86

以下も参照してください:

Mac OS

XS コンパイルが必要なモジュールはほとんどの人々にとっては使えません; MacPerl はフリーでない(そして安くない!)コンパイラを使って ビルドされているからです。 MacPerl で動作する一部の XS モジュールはビルドされて CPAN でバイナリ形式で 配布されています。

ディレクトリは以下のように指定されます:

    volume:folder:file              for absolute pathnames
    volume:folder:                  for absolute pathnames
    :folder:file                    for relative pathnames
    :folder:                        for relative pathnames
    :file                           for relative pathnames
    file                            for relative pathnames

ファイルはディレクトリにアルファベット順に保管されます。 ファイル名は 31 文字に制限され、null と、パス区切りとして予約されている : 以外の任意の文字を含むことができます。

flock に代わりに、Mac::Files モジュールの FSpSetFLock と FSpRstFLock、または chmod(0444, ...) と chmod(0666, ...) を 参照してください。

MacPerl アプリケーションでは、コマンドラインからプログラムを 実行することはできません; @ARGV が展開されることを想定しているプログラムは 以下のような感じに修正され、コマンドライン引数を訊ねるダイアログボックスが 作成されます。

    if (!@ARGV) {
        @ARGV = split /\s+/, MacPerl::Ask('Arguments?');
    }

"droplet" として保存された MacPerl スクリプトは、スクリプトにドロップされた ファイルのフルパス名を @ARGV に展開します。

Mac ユーザーは MPW (Macintosh Programmer's Workshop, Apple によるフリーな 開発環境) でのコマンドラインインターフェースでプログラムを実行できます。 MacPerl は最初 MPW ツールとして導入され、MPW はシェルのようにして使えます:

    perl myscript.plx some arguments

ToolServer は Apple によるもう一つの app で、MPW と MacPerl app から MPW tools へのアクセスを提供します; MacPerl プログラムが system, 逆クォート、パイプ open を使えるようにします。

"Mac OS" はオペレーティングシステムとして適切な名前ですが、$^O の値は "MacOS"。 アーキテクチャ、バージョン、アプリケーションか MPW tool 版が 実行されているかを決定するには、以下のようにチェックしてください:

    $is_app    = $MacPerl::Version =~ /App/;
    $is_tool   = $MacPerl::Version =~ /MPW/;
    ($version) = $MacPerl::Version =~ /^(\S+)/;
    $is_ppc    = $MacPerl::Architecture eq 'MacPPC';
    $is_68k    = $MacPerl::Architecture eq 'Mac68K';

NeXT's OpenStep OS を基にした Mac OS X は "Classic" 環境で MacPerl をネイティブに実行します。 基本的な Mac OS X 環境で動作させるための "Carbon" 版の MacPerl はありません。 Mac OS X とそのオープンソース版である Darwin の両方は Unix perl を ネイティブに実行します。

以下も参照してください:

VMS

VMS での Perl は perl 配布の perlvms で議論されています。

これを書いている時点での VMS の正式名称は OpenVMS です。

VMS での Perl は、 VMS 形式と Unix 形式のファイル指定の両方を、 以下のどちらかの形でも受け付けます:

    $ perl -ne "print if /perl_setup/i" SYS$LOGIN:LOGIN.COM
    $ perl -ne "print if /perl_setup/i" /sys$login/login.com

しかし以下のように両方を混ぜることはできません:

    $ perl -ne "print if /perl_setup/i" sys$login:/login.com
    Can't open sys$login:/login.com: file specification syntax error

Perl と Digital Command Language (DCL) シェルとの相互作用はしばしば Unix シェルが行うのとことなるクォートの種類が必要になります。 例えば:

    $ perl -e "print ""Hello, world.\n"""
    Hello, world.

もしそうしたいなら、DCL .COM ファイルに perl スクリプトをラップする いくつかの方法があります。 例えば:

    $ write sys$output "Hello from DCL!"
    $ if p1 .eqs. ""
    $ then perl -x 'f$environment("PROCEDURE")
    $ else perl -x - 'p1 'p2 'p3 'p4 'p5 'p6 'p7 'p8
    $ deck/dollars="__END__"
    #!/usr/bin/perl
    print "Hello from Perl!\n";
    __END__
    $ endif

perl-in-DCL スクリプトで $read = <STDIN>; のようなことを することを想定しているなら、$ ASSIGN/nolog/user SYS$COMMAND: SYS$INPUT に 注意してください。

VMS オペレーティングシステムには、ODS-2 および ODS-5 として知られる 二つのファイルシステムがあります。

ODS-2 では、ファイル名は "name.extension;version" の形式です。 ファイル名の最大長は 39 文字で、拡張子の最大長も 39 文字です。 version は 1 から 32767 の数値です。 妥当な文字は /[A-Z0-9$_-]/ です。

ODS-2 ファイルシステムでは大文字小文字を無視し、大文字小文字を保存しません。 Perl は、全てのファイル名を内部で小文字に変換することでこれを シミュレートします。

ODS-5 では、ファイル名はほとんどどんな文字でも使え、Unicode 文字も使えます。 DCL シェルやファイルパースユーティリティによって誤解釈されるかもしれない 文字は ^ 文字を前置するか、^ 文字を前置した 16 進文字で置き換える 必要があります。 このような前置はパス名がアプリケーション中で VMS 形式の時にのみ必要です。 UNIX 形式のパス名を受け付けるプログラムは文字をエスケープする必要は ありません。 ファイル名の最大長は 255 文字です。 ODS-5 ファイルシステムは大文字小文字を保存して大文字小文字を認識するモードの 両方を扱えます。

ODS-5 は 64 ビットプラットフォームの OpenVMS でのみ利用可能です。

拡張ファイル仕様対応は以前の VMS の制限を仮定する Perl スクリプトとの 後方互換性を保存するためにオプションの設定として行われます。

VMS で UNIX 形式ファイル仕様を使う一般的なルーチンでは、UNIX 形式で 返すべきで、VMS 形式仕様を受け取った場合は、変換すると文書化されていない限り VMS 形式を返すべきです。

返すファイル定義を生成するルーチンでは、VMS では Perl がビルドされた C ライブラリが VMS 形式を返すか UNIX 形式を返すかを設定できます。

ODS-2 ファイルシステムでは、パスを除くファイル名の文法は VMS や UNIX とあまり変わりません。 ODS-5 で利用可能な拡張文字集合では大きな違いがあります。

このため、VMS のために書かれた既にある Perl スクリプトは時毒 VMS と UNIX ファイル名を交換可能としています。 拡張文字集合が有効でなければ、この振る舞いはほとんど後方互換性のために 維持されています。

ODS-5 で拡張文字が有効の場合、UNIX 形式のファイル仕様の扱いは UNIX システムのものです。

拡張子なしの VMS ファイル仕様は末尾にドットがあります。 等価な UNIX ファイル仕様は末尾のドットを表示しないべきです。

これら全ての結果として、VMS での移植性のあるスクリプトとしては、Perl が ファイル名が小文字で表現されていたり、大文字小文字を区別したり、 ファイル名が UNIX または VMS 形式のどちらかで返されるということに 依存できません。

そしてあるルーチンがあるファイル仕様を返すなら、それが変換を意図していない 限り、見つけたのと同じ形式で返されるべきです。

デフォルトの readdir は伝統的に小文字のファイル名を返します。 ODS-5 対応が有効のとき、ディスク上のファイル名の正確な大文字小文字を 返します。

拡張子なしのファイルは末尾にピリオドが突いているので、A.;5 という名前に デフォルトモードで readdir を行うと、VMS では a. を返します(しかしこの ファイルは open(FH, 'A') で開けます).

拡張ファイル仕様に対応していて opendir が UNIX 形式のディレクトリを 与えられると、A.;5 という名前のファイルは a を返し、オプションとして ディスク上の正確な大文字小文字を返します。 opendir が VMS 形式ディレクトリを与えられると、readdir は a. を 返し、オプションとして正確な大文字小文字を返します。

VMS 7.2 以前および、VAX の VMS では 7.3 も、RMS には任意の論理ルートからの ディレクトリの深さは8 レベルに制限されています(全体では 16 レベル)。 従って PERL_ROOT:[LIB.2.3.4.5.6.7.8] は妥当なディレクトリ指定ですが PERL_ROOT:[LIB.2.3.4.5.6.7.8.9] は違います。 Makefile.PL の作者はこれを考えに入れておく必要があるかもしれませんが、 少なくとも前者は /PERL_ROOT/lib/2/3/4/5/6/7/8/ として参照できます。

パンプキングとモジュール統合者は、以下をトップレベルソースディレクトリで 実行することで、深すぎるディレクトリレベルを持つファイルがコアを ハングさせるかどうかを簡単に調べられます:

   $ perl -ne "$_=~s/\s+.*//; print if scalar(split /\//) > 8;" < MANIFEST

VMS のビルドプロセスの一部としてインストールされる VMS::Filespec モジュールは簡単に非 VMS プラットフォームにインストール出来て RSM ネイティブ形式との変換の助けとなるピュア Perl モジュールです。 これはいまでは VMS が大文字小文字を区別するモードかどうかをチェックする 唯一の方法です。

\n が表現しているものはファイルを開く種類に依存します。 普通は \012 を表現しますが、ファイルの構成や記録形式に依存して \015, \012, \015\012, \000, \040 あるいは 何もなしかもしれません。 VMS::Stdio モジュールは VMS での普通でない属性付きのファイルの 特殊な fopen() へのアクセスを提供します。

TCP/IP スタックは VMS ではオプションなので、ソケットルーチンは 実装されていません。 UDP ソケットは対応していません。

現在の全てのバージョンの VMS の TCP/IP ライブラリ対応は、もしあれば 動的に読み込まれるので、ルーチンが設定されていたとしても、 未実装を湿るステータスを返すかもしれません。

OpenVMS での $^O の値は "VMS" です。 %Config を全て読み込むという手段を使わずに実行しているアーキテクチャを 決定するには、以下のようにして @INC 配列の中身を確認します:

    if (grep(/VMS_AXP/, @INC)) {
        print "I'm on Alpha!\n";
    } elsif (grep(/VMS_VAX/, @INC)) {
        print "I'm on VAX!\n";
    } elsif (grep(/VMS_IA64/, @INC)) {
        print "I'm on IA64!\n";
    } else {
        print "I'm not so sure about where $^O is...\n";
    }

一般的に、顕著な違いは Perl が VMS_VAX または 64 ビット OpenVMS プラットフォームのどれかで実行されているときにのみあります。

VMS では、perl は UTC オフセットを SYS$TIMEZONE_DIFFERENTIAL 論理名から 決定します。 VMS の紀元は 17-NOV-1858 00:00:00.00 に始まりますが、localtime の呼び出しは Unix と同様 01-JAN-1970 00:00:00.00 からのオフセットに調整されます。

以下も参照してください:

VOS

VOS での Perl は perl 配布の README.vos (perlvos として インストールされます) で議論されています。 VOS での Perl は、以下のどちらかのようにして、VOS 形式と Unix 形式のどちらのファイル指定も受け付けます:

    $ perl -ne "print if /perl_setup/i" >system>notices
    $ perl -ne "print if /perl_setup/i" /system/notices

あるいは両方を混ぜて:

    $ perl -ne "print if /perl_setup/i" >system/notices

VOS はオブジェクト名としてスラッシュ文字が現れることを許していますが、 VOS 版の Perl インタプリタはこれをパス名を分割する文字として解釈するので、 名前にスラッシュ文字を含む VOS ファイル、ディレクトリ、リンクは 処理できません。 このようなファイルは Perl によって処理される前に リネームされなければなりません。 VOS はファイル名を 32 文字以下に制限していたり、ファイル名を - 文字で 始められなかったり、tr/ !%&'()*+;<>?// にマッチングする 文字を含むことができないことに注意してください。

VOS での $^O の値は "VOS" です。 %Config を全て読み込むという手段を使わずに実行しているアーキテクチャを 決定するには、以下のようにして @INC 配列の中身を確認します:

    if ($^O =~ /VOS/) {
        print "I'm on a Stratus box!\n";
    } else {
        print "I'm not on a Stratus box!\n";
        die;
    }

以下も参照してください:

EBCDIC プラットフォーム

最近のバージョンの Perl は AS/400 マイクロコンピュータでの OS/400、 S/390 メインフレームでの OS/390, VM/ESA, BS2000 のようなプラットフォームに 移植されています。 このようなコンピュータは内部で EBCDIC 文字集合 (通常は OS/400 では Character Code Set ID 0037、S/390 では 1047 または POSIX-BC の どちらか) を内部で使います。 メインフレーム perl は現在のところ "Unix system services for OS/390" (以前は OpenEdition として知られていたもの), VM/ESA OpenEdition, BS200 POSIX-BC システムで動作します (BS2000 は 5.6 以降で対応します)。 詳しくは perlos390 を参照してください。 OS/400 には (EBCDIC ベースの ILE ではなく) ASCII ベースの PASE への Perl 5.8.1/5.9.0 以降の移植もあることに注意してください; perlos400 を 参照してください。

OS/390 の USS の R2.5 および VM/ESA のバージョン 2.3 以降、 これらの Unix 副システムはスクリプトの起動のための #! トリックに 対応しなくなりました。 従って、OS/390 と VM/ESA では perl スクリプトは以下のような単純な スクリプトと似たヘッダ付きで実行できます:

    : # use perl
        eval 'exec /usr/local/bin/perl -S $0 ${1+"$@"}'
            if 0;
    #!/usr/local/bin/perl     # just a comment really
    print "Hello from perl!\n";

OS/390 はリリース 2.8 以降、#! トリックに対応しています。 system と逆クォートの呼び出しは全ての S/390 システムで POSIX シェル文法を 使います。

AS/400 では、ライブラリリストに PERL5 があれば、以下のようにして CL 手続きで perl スクリプトをラップする必要があります:

    BEGIN
      CALL PGM(PERL5/PERL) PARM('/QOpenSys/hello.pl')
    ENDPGM

これは QOpenSys ファイルシステムのルートにある perl スクリプト hello.pl を起動します。 AS/400 では system や逆クォートの呼び出しは CL 文法を 使わなければなりません。

これらのプラットフォームでは、(chr, pack, print, printf, ord, sort, sprintf, unpack のような) 一部の perl の関数および、^, &, | のような演算子を使った ASCII 定数のビット操作での効果が EBCDIC 文字では異なることがあることに 注意してください; ASCII コンピュータへのソケットインターフェースを 扱うことを言及しません (改行 参照)。

幸いにも、メインフレームのほとんどの web サーバは以下の文の \n を ASCII の等価物に正しく変換します (\r は Unix と OS/390 & VM/ESA で同じです):

    print "Content-type: text/html\r\n\r\n";

これらのプラットフォームの $^O の値は以下のようなものです:

    uname         $^O        $Config{'archname'}
    --------------------------------------------
    OS/390        os390      os390
    OS400         os400      os400
    POSIX-BC      posix-bc   BS2000-posix-bc
    VM/ESA        vmesa      vmesa

EBCDIC プラットフォームで実行されているかどうかを決定するための 単純なトリックとしては、以下のどれか(おそらく全て)があります:

    if ("\t" eq "\05")   { print "EBCDIC may be spoken here!\n"; }
    if (ord('A') == 193) { print "EBCDIC may be spoken here!\n"; }
    if (chr(169) eq 'z') { print "EBCDIC may be spoken here!\n"; }

依存したいと思わないだろうことの一つは、句読点文字の EBCDIC エンコードでしょう; これらはコードページによって異なるからです (そして一旦あなたのモジュールやスクリプトが EBCDIC で動作すると噂されると、 人々は全ての EBCDIC 文字集合で動作することを求めます)。

以下も参照してください:

Acorn RISC OS

Acorns は Unix と同様 ASCII を使い、テキストファイルの改行 (\n) に \012 を使うのと、Unix ファイル名エミュレーションがデフォルトで 有効なので、ほとんどの単純なスクリプトはおそらく「そのまま」で動作します。 ネイティブなファイルシステムはモジュラー形式で、個々のファイルシステムは 大文字小文字を区別するかしないかは関係なく、普通は大文字小文字を保存します。 ネイティブなファイルシステムの一部は名前の長さに制限があり、 ファイル名とディレクトリ名は収まるように暗黙に切り詰められます。 スクリプトは、標準ファイルシステムは名前の長さが 10 に制限され、一つの ディレクトリに77 アイテムまでに制限されることに注意するべきです; しかし他のファイルシステムはこのような制限はないかもしれません。

ネイティブなファイル名は以下の形式です:

    Filesystem#Special_Field::DiskName.$.Directory.Directory.File

それぞれは以下の通りです:

    Special_Field is not usually present, but may contain . and $ .
    Filesystem =~ m|[A-Za-z0-9_]|
    DsicName   =~ m|[A-Za-z0-9_/]|
    $ represents the root directory
    . is the path separator
    @ is the current directory (per filesystem but machine global)
    ^ is the parent directory
    Directory and File =~ m|[^\0- "\.\$\%\&:\@\\^\|\177]+|

デフォルトファイル名変換はだいたい tr|/.|./|; です。

"ADFS::HardDisk.$.File" ne 'ADFS::HardDisk.$.File' と、正規表現中の $ 展開の第 2 ステージは、スクリプトが注意深くなければ $. を 落とすことに注意してください。

カンマ区切りの検索リストを含むシステム変数で指定された論理パスも使えます; 従って System:Modules は妥当なファイル名で、 ファイルシステムは、名前がディスク上のオブジェクトを指すようになるまで System$Path のそれぞれの部分に Modules を前置します。 System$Path に単一のアイテムリストが含まれている場合にのみ、 新しいファイル System:Modules に書き込めます。 ファイルシステムはファイル名にシステム変数が角かっこで囲まれていると 展開するので、 <System$Dir>.Modules は $ENV{'System$Dir'} . 'Modules' というファイルを探します。 ここから明らかに推測されることは、 完全修飾ファイル名は <> で始まることがあり、open が 入力で使われるときは保護されるべきということです。

. がディレクトリセパレータとして使われていて、ファイル名の 10 文字目 以降はユニークであると仮定できないので、Acorn はソースコード中に指定された ファイル名から末尾の .c .h .s, .o 拡張子を切り落として、 拡張子の名前のサブディレクトリにそれぞれのファイルを保管するような形で C コンパイラを実装しました。 従ってファイルは変換されます:

    foo.h           h.foo
    C:foo.h         C:h.foo        (logical path variable)
    sys/os.h        sys.h.os       (C compiler groks Unix-speak)
    10charname.c    c.10charname
    10charname.o    o.10charname
    11charname_.c   c.11charname   (assuming filesystem truncates at 10)

Unix エミュレーションライブラリのファイル名のネイティブへの変換は この種の変換が必要であることを仮定していて、この方法で入れ替える既知の 拡張子のリストをユーザー定義できるようになっています。 これは透過的に思えますが、これらの規則では foo/bar/baz.h と foo/bar/h/baz の両方が foo.bar.h.baz にマッピングされ、readdir と glob は逆マッピングのエミュレートを試みることができないことを 考慮してください。 ファイル名中のその他の . は / に変換されます。

すでに暗示したように、%ENV を通してアクセスする環境はグローバルで、 プログラム固有環境変数は Program$Name の形に変換されます。 それぞれのファイルシステムはカレントディレクトリを管理し、現在の ファイルシステムのカレントディレクトリは グローバルな カレントディレクトリです。 従って、社交的なプログラムはカレントディレクトリを変更せずに フルパス名に頼り、プログラム(および Makefile) は親 (およびこの意味では その他あらゆるもの)に影響を与えずにカレントディレクトリを変更できる 子プロセスを作成できると仮定できません。

ネイティブオペレーティングシステムファイルハンドルはグローバルで 現在のところ 255 から下向きに割り当てられ、0 は予約された値なので、 Unix エミュレーションライブラリは Unix ファイルハンドルをエミュレートします。 従って、STDIN, STDOUT, STDERR を子プロセスに渡すことに 頼れません。

コマンドラインでクォートなしに <Foo$Dir>.Bar 形式のファイル名を 記述するというユーザーの欲求も問題を引き起こします: `` コマンド出力 捕捉は推論ゲームをする必要があります。 <[^<>]+\$[^<>]> は環境変数の参照、それ以外の < や > が 関係する全てはリダイレクトと推測し、これは一般的に何とか 99% は正しいです。 もちろん、スクリプトはどの Unix ツールが利用可能であることや、見つけた ツールが Unix 風のコマンドライン引数を取ることには頼れないという問題は 残っています。

エクステンションと XS は、理論的には、自由なツールを使って誰でも ビルドできます。 実際には、多くの人はできません; Acorn プラットフォームのユーザーは バイナリ配布を使っているからです。 MakeMaker は実行できますが、現在のところ MakeMaker の makefile を処理できる make はありません; たとえこれが修正されても、Unix 風シェルがないので makefile 規則で問題が起こります; 特に cd sdbm && make all 形式の行や、 クォートを使ったものです。

"RISC OS" はオペレーティングシステムの適切な名前ですが、$^O の値は "riscos" (大文字は好まないからです)。

その他の perl

Perl は上述したカテゴリ一覧のどれにも当てはまらないような多くの プラットフォームに移植されています。 AmigaOS, Atari MiNT, BeOS, HP MPE/iX, QNX, Plan 9, VOS のような 一部のものは標準 Perl ソースコードキットとよく統合されています。 Atari ST, lynxos, riscos, Novell Netware, Tandem Guardian など の ようなものについての情報とおそらくバイナリを得るために CPAN の ports/ ディレクトリを見る必要があるかもしれません: (はい、これらの OS の一部は Unix カテゴリに入ることを知っていますが、 私たちは標準の組織ではありません。)

"OTHER" カテゴリにあるいくつかの近似オペレーティングシステム名と その $^O の値は以下のようなものです:

    OS            $^O        $Config{'archname'}
    ------------------------------------------
    Amiga DOS     amigaos    m68k-amigos
    BeOS          beos
    MPE/iX        mpeix      PA-RISC1.1

以下も参照してください:

関数実装

以下の一覧は、プラットフォームによって全く実装されていないか、 さもなければ異なった形で実装されている関数です。 それぞれの記述にあるかっこは、記述が適用されるプラットフォームの一覧です。

一覧は不完全であったり、一部で間違っている可能性があります。 疑わしいときは、Perl ソース配布のプラットフォーム固有の README ファイルや、 プラットフォームに関連するその他の文書リソースをチェックしてください。

さらに、Unix 風システムにもバリエーションがあることに注意してください。

多くの関数に関して、Config モジュールからデフォルトでエクスポートされる %Config に問い合わせることもできます。 例えば、プラットフォームに lstat 呼び出しがあるかどうかを調べるには、 $Config{d_lstat} を調べてください。 利用可能な変数の完全な説明については Config を参照してください。

Perl 関数のアルファベット順リスト

-X

-r, -w, -x は限られた意味しかありません; ディレクトリと アプリケーションは実行可能で、uid/gid という概念はありません。 -o は対応していません。 (Mac OS)

-w は読み込み専用ファイル属性 (FILE_ATTRIBUTE_READONLY) のみを調べます; これはディレクトリに書き込めるかどうかではなくディレクトリが 削除できるかどうかを決定します。 ディレクトリは、随意アクセス制御リスト (DACL) で拒否されない限り、常に 読み書きアクセスできます。 (Win32)

-r, -w, -x, -o はファイルがアクセス可能かどうかを返し、 UIC ベースのファイル保護を反映しません。 (VMS)

-s はデータフォークとリソースフォークの合計サイズではなく、 データフォークのサイズを返します。 (Mac OS)

開いているファイルへの名前での -s は、現在のエクステントではなく、 ディスク上に予約されている空間を返します。 開いているファイルハンドルへの -s は現在のサイズを返します。 (RISC OS)

-R, -W, -X, -O は、-r, -w, -x, -o と 区別が付きません。 (Mac OS, Win32, VMS, RISC OS)

-b, -c, -k, -g, -p, -u, -A は実装されていません。 (Mac OS)

-g, -k, -l, -p, -u, -A は特に意味はありません。 (Win32, VMS, RISC OS)

-d は、明示的なディレクトリなしに device spec を渡されると真になります。 (VMS)

-T と -B は実装されていますが、外国語文字が含まれた Mac text ファイルを間違って判定することがありました; これは全ての プラットフォームで起こりますが、Mac OS でよく影響を受けます。 (Mac OS)

-x (または -X) はファイルが実行可能ファイルの拡張子のどれかで 終わっているかを判定します。 -S は無意味です。 (Win32)

-x (または -X) ファイルが実行可能ファイル型かどうかを 決定します。 (RISC OS)

atan2

様々な CPU、数値演算ライブラリ、コンパイラ、標準の問題により、atan2() の 結果は上述の組み合わせに依存して様々に異なります。 Perl は atan2() から返される結果を Open Group/IEEE 標準に 準拠させようとしますが、システムの Perl がそれを許さないところで 動作している場合は問題を強制させることはできません。 (Tru64, HP-UX 10.20)

atan2() の現在のバージョンの標準は http://www.opengroup.org/onlinepubs/009695399/functions/atan2.html で 利用可能です。

binmode

無意味です。 (Mac OS, RISC OS)

ファイルの再オープンとポインタの復帰; 関数が失敗すると、基となる ファイルハンドルが閉じられたり、ポインタが異なった位置を示すことが あります。 (VMS)

tell から返された値はこの呼び出しの後に影響を受けることがあり、 ファイルハンドルがフラッシュされることがあります。 (Win32)

chmod

限られた意味しかありません。 書き込み権限の無効/有効はファイルのロック/アンロックに割り当てられます。 (Mac OS)

「所有者」読み書きアクセスの変更のみ動作し、「グループ」「その他」のビットは 無意味です。 (Win32)

「所有者」と「その他」の読み書きアクセスの変更のみ動作します。 (RISC OS)

アクセス許可は VOS アクセス制御リスト変更に割り当てられます。 (VOS)

実際の許可は SYSTEM 環境設定の CYGWIN の値に依存して設定されます。 (Cygwin)

chown

実装されていません。 (Mac OS, Win32, Plan 9, RISC OS)

何もしませんが失敗もしません。 (Win32)

VOS での所有者の概念は少し変なので、少し変です。 (VOS)

chroot

実装されていません。 (Mac OS, Win32, VMS, Plan 9, RISC OS, VOS, VM/ESA)

crypt

perl のビルド時にライブラリかソースが提供されていないと 利用できないかもしれません。 (Win32)

dbmclose

実装されていません。 (VMS, Plan 9, VOS)

dbmopen

実装されていません。 (VMS, Plan 9, VOS)

dump

使い道はありません。 (Mac OS, RISC OS)

対応していません。 (Cygwin, Win32)

VMS デバッガを起動します。 (VMS)

exec

実装されていません。 (Mac OS)

Spawn で実装されています。 (VM/ESA)

一部のプラットフォームでは出力ハンドルを自動的にフラッシュしません。 (SunOS, Solaris, HP-UX)

exit

1 を SS$_ABORT (44) にマッピングすることで UNIX の (エラーを示すために exit 1 を使う) exit() をエミュレートします。 この振る舞いはプラグマ use vmsish 'exit' で上書きされます。 CRTL の exit() 関数と同様、exit 0 は SS$_NORMAL の終了ステータス (1) にマッピングされます; このマッピングは上書きできません。 exit() へのその他の引数は直接 Perl の終了ステータスとして使われます。 VMS では、将来の POSIX_EXIT モードが有効でない限り、終了コードは 常に有効な VMS 終了コードであり、一般的な数値ではないべきです。 POSIX_EXIT モードが有効なら、一般的な数値は C ライブラリの _POSIX_EXIT と 互換性のあるメソッドにエンコードされるので、その他のプログラム、特に GNV パッケージのような C で書かれているプログラムでデコードできます。 (VMS)

fcntl

実装されていません。 (Win32) 一部の関数は VMS のバージョンによっては利用可能です。 (VMS)

flock

実装されていません。 (Mac OS, VMS, RISC OS, VOS)

Windows NT でのみ利用可能です (Windows 95 では動作しません)。 (Win32)

fork

実装されていません。 (Mac OS, AmigaOS, RISC OS, VM/ESA, VMS)

複数のインタプリタを使ってエミュレートされています。 perlfork を参照してください。 (Win32)

一部のプラットフォームでは出力ハンドルを自動的にフラッシュしません。 (SunOS, Solaris, HP-UX)

getlogin

実装されていません。 (Mac OS, RISC OS)

getpgrp

実装されていません。 (Mac OS, Win32, VMS, RISC OS)

getppid

実装されていません。 (Mac OS, Win32, RISC OS)

getpriority

実装されていません。 (Mac OS, Win32, VMS, RISC OS, VOS, VM/ESA)

getpwnam

実装されていません。 (Mac OS, Win32)

使い道はありません。 (RISC OS)

getgrnam

実装されていません。 (Mac OS, Win32, VMS, RISC OS)

getnetbyname

実装されていません。 (Mac OS, Win32, Plan 9)

getpwuid

実装されていません。 (Mac OS, Win32)

使い道はありません。 (RISC OS)

getgrgid

実装されていません。 (Mac OS, Win32, VMS, RISC OS)

getnetbyaddr

実装されていません。 (Mac OS, Win32, Plan 9)

getprotobynumber

実装されていません。 (Mac OS)

getservbyport

実装されていません。 (Mac OS)

getpwent

実装されていません。 (Mac OS, Win32, VM/ESA)

getgrent

実装されていません。 (Mac OS, Win32, VMS, VM/ESA)

gethostbyname

gethostbyname('localhost') はどこでも動作するわけではありません: gethostbyname('127.0.0.1') を使う必要があるかもしれません。 (Mac OS, Irix 5)

gethostent

実装されていません。 (Mac OS, Win32)

getnetent

実装されていません。 (Mac OS, Win32, Plan 9)

getprotoent

実装されていません。 (Mac OS, Win32, Plan 9)

getservent

実装されていません。 (Win32, Plan 9)

sethostent

実装されていません。 (Mac OS, Win32, Plan 9, RISC OS)

setnetent

実装されていません。 (Mac OS, Win32, Plan 9, RISC OS)

setprotoent

実装されていません。 (Mac OS, Win32, Plan 9, RISC OS)

setservent

実装されていません。 (Plan 9, Win32, RISC OS)

endpwent

実装されていません。 (Mac OS, MPE/iX, VM/ESA, Win32)

endgrent

実装されていません。 (Mac OS, MPE/iX, RISC OS, VM/ESA, VMS, Win32)

endhostent

実装されていません。 (Mac OS, Win32)

endnetent

実装されていません。 (Mac OS, Win32, Plan 9)

endprotoent

実装されていません。 (Mac OS, Win32, Plan 9)

endservent

実装されていません。 (Plan 9, Win32)

getsockopt SOCKET,LEVEL,OPTNAME

実装されていません。 (Plan 9)

glob

この演算子はほとんどのプラットフォームでは File::Glob エクステンションで 実装されています。 移植性の情報については File::Glob を参照してください。

gmtime

localtime と同じ移植性の問題があります。

ioctl FILEHANDLE,FUNCTION,SCALAR

実装されていません。 (VMS)

ソケットハンドルに対してのみ利用可能で、Winsock API の ioctlsocket() 呼び出しですることをします。 (Win32)

ソケットハンドルに対してのみ利用可能です。 (RISC OS)

kill

kill(0, LIST) は汚染チェックのために実装されています; 他のシグナルでの使用は実装されていません。 (Mac OS)

汚染チェックには有用ではないので、実装されていません。 (RISC OS)

kill() は raise() の動作はありません; つまり、 Unix プラットフォームで行われるように識別されたプロセスへシグナルを 送りません。 代わりに kill($sig, $pid) は $pid で識別されるプロセスを終了させ、 終了コード $sig で直ちに終了させます。 Unix でのように、$sig が 0 で指定されたプロセスが存在するなら、実際には 終了させずに真を返します。 (Win32)

kill(-9, $pid) は $pid で指定されたプロセスと、そのプロセスが 所有している全ての子プロセスを再帰的に終了させます。 これは、$pid で指定されたプロセスと同じプロセスグループの全ての プロセスにシグナルを送信する、という Unix での動作と異なります。 (Win32)

プロセス識別番号 0 や負数は対応していません。 (VMS)

link

実装されていません。 (Mac OS, MPE/iX, RISC OS)

ハードリンクは完全にハードではないので、リンクカウントは更新されません (これはハードリンクとソフトリンクの中間のようなものです)。 (AmigaOS)

ハードリンクは NTFS の Win32 にのみ実装されています。 これは Windows 2000 以降でネイティブに対応しています。 Windows NT では Windows POSIX サブシステムサポートを使って 実装されていて、Perl プロセスはハードリンクを作るには Administrator または Backup Operator 権限が必要です。

64 ビット OpenVMS 8.2 以降で利用可能です。 (VMS)

localtime

Perl は現在のところネイティブな標準 C localtime() 関数に依存しているので、 0 と (2**31)-1 の間でのみ times を使うのが安全です。 この範囲外の times はオペレーティングシステムの localtime() の実装に依存して 想定外の振る舞いになることがあります。

lstat

実装されていません。 (RISC OS)

返り値 (特にデバイスと i ノード) は偽物かもしれません。 (Win32)

msgctl
msgget
msgsnd
msgrcv

実装されていません。 (Mac OS, Win32, VMS, Plan 9, RISC OS, VOS)

open

| 関連は ToolServer がインストールされているときにのみ対応します。 (Mac OS)

|- と -| へのオープンは対応していません。 (Mac OS, Win32, RISC OS)

プロセスをオープンしたときに一部のプラットフォームでは出力ハンドルを自動的に フラッシュしません。 (SunOS, Solaris, HP-UX)

pipe

とても限定した機能しかありません。 (MiNT)

readlink

実装されていません。 (Win32, VMS, RISC OS)

rename

異なった論理ボリュームのディレクトリの間ではディレクトリは移動できません。 (Win32)

select

ソケットに対してのみ実装されています。 (Win32, VMS)

ソケットに対してのみ信頼できます。 (RISC OS)

select FILEHANDLE 形式は一般的に移植性があることに注意してください。

semctl
semget
semop

実装されていません。 (Mac OS, Win32, VMS, RISC OS, VOS)

setgrent

実装されていません。 (Mac OS, MPE/iX, VMS, Win32, RISC OS, VOS)

setpgrp

実装されていません。 (Mac OS, Win32, VMS, RISC OS, VOS)

setpriority

実装されていません。 (Mac OS, Win32, VMS, RISC OS, VOS)

setpwent

実装されていません。 (Mac OS, MPE/iX, Win32, RISC OS, VOS)

setsockopt

実装されていません。 (Plan 9)

shmctl
shmget
shmread
shmwrite

実装されていません。 (Mac OS, Win32, VMS, RISC OS, VOS)

sockatmark

比較的最近に追加されたソケット関数で、UNIX プラットフォームであっても 実装されていないかもしれません。

socketpair

実装されていません。 (RISC OS, VOS, VM/ESA)

64 ビット OpenVMS 8.2 以降で利用可能です。 (VMS)

stat

rdev, blksize, blocks がないプラットフォームではこれらは '' を返すので、 これらのフィールドの数値での比較や操作は 'not numeric' 警告を 引き起こします。

mtime と atime は同じもので、ctime は i ノード変更時刻ではなく作成時刻です。 (Mac OS)

ctime は UFS では対応していません。 (Mac OS X)

ctime は i ノード変更時刻ではなく作成時刻です。 (Win32)

デバイスと i ノードは無意味です。 (Win32)

デバイスと i ノードは信頼できる必要がありません。 (VMS)

mtime, atime, ctime は全て最終更新時刻を返します。 デバイスと i ノードは信頼する必要はありません。 (RISC OS)

dev, rdev, blksize, blocks は利用できません。 inode は無意味で、同じファイルで stat 呼び出しの間でも異なります。 (os2)

cygwin の一部のバージョンでは、stat("foo") を実行して、もし 見付からなければ stat("foo.exe") を実行しようとします。 (Cygwin)

Win32 では stat() は、リンクカウントと、ハードリンクを通して 変更されるかもしれない属性の更新にはファイルを開く必要があります。 ${^WIN32_SLOPPY_STAT} を真の値に設定することで、この操作をしないことで stat() を高速化します。 (Win32)

symlink

実装されていません。 (Win32, RISC OS)

64 ビット VMS 8.3 で実装されています。 VMS は、有効なパスを解決することを目的としているなら、シンボリックリンクが Unix の文法であることが必要です。

syscall

実装されていません。 (Mac OS, Win32, VMS, RISC OS, VOS, VM/ESA)

sysopen

伝統的なl "0", "1", 2" の MODE は一部のシステムでは異なる数値で 実装されています。 しかし、Fcntl でエクスポートされるフラグ (O_RDONLY, O_WRONLY, O_RDWR) は どこでも動作するはずです。 (Mac OS, OS/390, VM/ESA)

system

ToolServer がインストールされているときにのみ実装されています。 (Mac OS)

最適化として、$ENV{PERL5SHELL} で指定されたコマンドシェルを 呼び出さないかもしれません。 system(1, @args) は外部プロセスを起動して、その終了を待たず、 直ちにそのプロセス指定子を返します。 返り値は引き続く wait や waitpid で使えます。 サブプロセスの spawn() の失敗は、$? に "255 << 8" を設定することで 示されます。 $? は Unix と互換性のある方法 (つまり、サブプロセスの終了ステータスは 文書に記述されている通りに "$? >> 8" で得られる) で設定されます。 (Win32)

メタ文字を処理するシェルはなく、ネイティブな標準では "\n", "\r", "\0" で終端されたコマンドラインを spawn したプログラムに 渡します。 > foo のようなリダイレクトは spawn したプログラムの ランタイムライブラリによって実行されます。 system list は Unix エミュレーションライブラリの exec エミュレーションを呼び出し、子プログラムがエミュレーションライブラリの 互換版を使っているなら、親の stdin, stdout, stderr をエミュレーションを 提供しようとします。 scalar はネイティブなコマンドラインを直接呼び出し、子 Unix プログラムの エミュレーションは存在しません。 これは状況によって 異なります。 (RISC OS)

POSIX 準拠からはほど遠いです。 基礎となる /bin/sh がないかもしれないので、引数文字列の最初のトークンを fork して実行することで問題を回避しようとします。 基本的なリダイレクト ("<" や ">") を自身に代わって扱います。 (MiNT)

一部のプラットフォームでは出力ハンドルを自動的にフラッシュしません。 (SunOS, Solaris, HP-UX)

返り値は POSIX 風 (8 ビットシフト) で、(use vmsish 'status' で 上書きされない限り)ネイティブな 32 ビット条件コードの重大度ビットから 作り上げられた値のための場所だけがあります。 ネイティブな条件コードが POSIX 値をエンコードしたものなら、 POSIX 値は想定される終了コードを展開するためにデコードされます。 さらなる詳細については perlvms/$? を参照してください。 (VMS)

times

返された最初のエントリが非 0 のときのみです。 (Mac OS)

「累積」時間は偽りかもしれません。 Windows NT と Windows 2000 以外では、「システム」時間は偽りかもしれず、 「ユーザ」時間は実際には C ランタイムライブラリの clock() 関数から かえされた時刻です。 (Win32)

使い道はありません。 (RISC OS)

truncate

実装されていません。 (Older versions of VMS)

同じかより短い長さへの切り詰めのみです。 (VOS)

FILEHANDLE が指定されると、それは書き込み可能で、追記モード (つまり open(FH, '>>filename') または sysopen(FH,...,O_APPEND|O_RDWR) を使っている)でなければなりません。 ファイル名が指定されると、他で開いていてはいけません。 (Win32)

umask

バージョン 5.005 から、利用不可能な場合は undef を返します。

umask は動作しますが、正しい権限はファイルが最終的に閉じられたときにのみ 設定されます。 (AmigaOS)

utime

修正時刻が更新されたときのみです。 (BeOS, Mac OS, VMS, RISC OS)

想定した通りに動作しないかもしれません。 振る舞いは C ランタイムライブラリの utime() の実装と、使われる ファイルシステムに依存します。 FAT ファイルシステムは典型的には「アクセス時刻」フィールドに 対応しておらず、タイムスタンプの制度が 2 秒に制限されているかも しれません。 (Win32)

wait
waitpid

実装されていません。 (Mac OS)

system(1, ...) を使って作成されたプロセスか、fork() で作成された 疑似プロセスで返されたプロセスハンドルに対してのみ適用できます。 (Win32)

使い道はありません。 (RISC OS)

対応しているプラットフォーム

2002 年 7 月 (Perl リリース 5.8.0) 現在、以下のプラットフォームが http://www.cpan.org/src/index.html から利用可能な標準ソースコード配布から ビルド可能です:

        AIX
        BeOS
        BSD/OS          (BSDi)
        Cygwin
        DG/UX
        DOS DJGPP       1)
        DYNIX/ptx
        EPOC R5
        FreeBSD
        HI-UXMPP        (Hitachi) (5.8.0 worked but we didn't know it)
        HP-UX
        IRIX
        Linux
        Mac OS Classic
        Mac OS X        (Darwin)
        MPE/iX
        NetBSD
        NetWare
        NonStop-UX
        ReliantUNIX     (formerly SINIX)
        OpenBSD
        OpenVMS         (formerly VMS)
        Open UNIX       (Unixware) (since Perl 5.8.1/5.9.0)
        OS/2
        OS/400          (using the PASE) (since Perl 5.8.1/5.9.0)
        PowerUX
        POSIX-BC        (formerly BS2000)
        QNX
        Solaris
        SunOS 4
        SUPER-UX        (NEC)
        Tru64 UNIX      (formerly DEC OSF/1, Digital UNIX)
        UNICOS
        UNICOS/mk
        UTS
        VOS
        Win95/98/ME/2K/XP 2)
        WinCE
        z/OS            (formerly OS/390)
        VM/ESA
        1) in DOS mode either the DOS or OS/2 ports can be used
        2) compilers: Borland, MinGW (GCC), VC6

以下のプラットフォームは以前のリリース (5.6 と 5.7) で動作していましたが、 5.8.0 リリースのときに修正やテストができませんでした。 これらの多くは 5.8.0 でうまく動く可能性がかなりあります。

        BSD/OS
        DomainOS
        Hurd
        LynxOS
        MachTen
        PowerMAX
        SCO SV
        SVR4
        Unixware
        Windows 3.1

5.8.0 で壊れていることが知られています (しかし 5.6.1 と 5.7.2 は使えます):

        AmigaOS

以下のプラットフォームは過去 (5.005_03 以前) にソースから Perl を ビルドしたことが知られていますが、現在のリリースに対する状況を 確認できません; ハードウェア/ソフトウェアプラットフォームがレアなものか、 これらのプラットフォームに対するアクティブな推進者がいないか、 あるいはその両方が理由です。 しかし以前は動いていたので、ぜひコンパイルしてみて、 perlbug@perl.org に 問題点を知らせてください。

        3b1
        A/UX
        ConvexOS
        CX/UX
        DC/OSx
        DDE SMES
        DOS EMX
        Dynix
        EP/IX
        ESIX
        FPS
        GENIX
        Greenhills
        ISC
        MachTen 68k
        MiNT
        MPC
        NEWS-OS
        NextSTEP
        OpenSTEP
        Opus
        Plan 9
        RISC/os
        SCO ODT/OSR
        Stellar
        SVR2
        TI1500
        TitanOS
        Ultrix
        Unisys Dynix

以下のプラットフォームは http://www.cpan.org/ports/ 経由で独自の ソースコード配布とバイナリが利用可能です:

                                Perl release
        OS/400 (ILE)            5.005_02
        Tandem Guardian         5.004

以下のプラットフォームは http://www.cpan.org/ports/index.html 経由で バイナリのみが利用可能です:

                                Perl release
        Acorn RISCOS            5.005_02
        AOS                     5.002
        LynxOS                  5.004_02

しかし、私たちは、最大限の設定可能性とセキュリティの両方のために、 常にあなた自身の Perl をソースからビルドすることを提案しています; 急いでいる場合には http://www.cpan.org/ports/index.html にある バイナリ配布をチェックしてください。

SEE ALSO

perlaix, perlamiga, perlapollo, perlbeos, perlbs2000, perlce, perlcygwin, perldgux, perldos, perlepoc, perlebcdic, perlfreebsd, perlhurd, perlhpux, perlirix, perlmachten, perlmacos, perlmacosx, perlmint, perlmpeix, perlnetware, perlos2, perlos390, perlos400, perlplan9, perlqnx, perlsolaris, perltru64, perlunicode, perlvmesa, perlvms, perlvos, perlwin32, and Win32.

AUTHORS / CONTRIBUTORS

Abigail <abigail@foad.org>, Charles Bailey <bailey@newman.upenn.edu>, Graham Barr <gbarr@pobox.com>, Tom Christiansen <tchrist@perl.com>, Nicholas Clark <nick@ccl4.org>, Thomas Dorner <Thomas.Dorner@start.de>, Andy Dougherty <doughera@lafayette.edu>, Dominic Dunlop <domo@computer.org>, Neale Ferguson <neale@vma.tabnsw.com.au>, David J. Fiander <davidf@mks.com>, Paul Green <Paul.Green@stratus.com>, M.J.T. Guy <mjtg@cam.ac.uk>, Jarkko Hietaniemi <jhi@iki.fi>, Luther Huffman <lutherh@stratcom.com>, Nick Ing-Simmons <nick@ing-simmons.net>, Andreas J. König <a.koenig@mind.de>, Markus Laker <mlaker@contax.co.uk>, Andrew M. Langmead <aml@world.std.com>, Larry Moore <ljmoore@freespace.net>, Paul Moore <Paul.Moore@uk.origin-it.com>, Chris Nandor <pudge@pobox.com>, Matthias Neeracher <neeracher@mac.com>, Philip Newton <pne@cpan.org>, Gary Ng <71564.1743@CompuServe.COM>, Tom Phoenix <rootbeer@teleport.com>, André Pirard <A.Pirard@ulg.ac.be>, Peter Prymmer <pvhp@forte.com>, Hugo van der Sanden <hv@crypt0.demon.co.uk>, Gurusamy Sarathy <gsar@activestate.com>, Paul J. Schinder <schinder@pobox.com>, Michael G Schwern <schwern@pobox.com>, Dan Sugalski <dan@sidhe.org>, Nathan Torkington <gnat@frii.com>. John Malmberg <wb8tyw@qsl.net>