- 名前
- 説明
- 問題
- CPAN Testers
- プラットフォーム
- 関数実装
- 対応しているプラットフォーム
- EOL プラットフォーム
- 対応していたプラットフォーム (Perl 5.8)
- SEE ALSO
- AUTHORS / CONTRIBUTORS
名前¶
perlport - Writing portable Perl
perlport - 移植性のある Perl を書く
説明¶
Perl runs on numerous operating systems. While most of them share much in common, they also have their own unique features.
Perl は多くのオペレーティングシステム上で動作します。 これらのほとんどは一般的にかなりの部分を共有していますが、それぞれ固有の 機能も持っています。
This document is meant to help you to find out what constitutes portable Perl code. That way once you make a decision to write portably, you know where the lines are drawn, and you can stay within them.
この文書は移植性のある Perl コードの構成要素を発見する助けになるための ものです。 移植性のある形で書こうと決心したら、どこに線が引かれているかを知ることで、 その内側に留まることができます。
There is a tradeoff between taking full advantage of one particular type of computer and taking advantage of a full range of them. Naturally, as you broaden your range and become more diverse, the common factors drop, and you are left with an increasingly smaller area of common ground in which you can operate to accomplish a particular task. Thus, when you begin attacking a problem, it is important to consider under which part of the tradeoff curve you want to operate. Specifically, you must decide whether it is important that the task that you are coding has the full generality of being portable, or whether to just get the job done right now. This is the hardest choice to be made. The rest is easy, because Perl provides many choices, whichever way you want to approach your problem.
ある特定の種類のコンピュータの利点を使うことと、あらゆる範囲の コンピュータの利点を使うことの間にはトレードオフがあります。 当然ながら、より範囲を広げてより多様性のある形にすると、共通の要素が 減っていき、特定のタスクを達成するために操作できる共通の地盤が徐々に 小さくなっていきます。 従って、問題に取りかかるときに、トレードオフのカーブのどの部分を 使うかを考えることは重要です。 特に、コーディングしようとするタスクが移植性に関して完全な一般性が 重要かどうか、またすぐにジョブを終わらせるかどうかを 決定しなければなりません。 残りのことは簡単です。 なぜならあなたが問題にどのようにアプローチしたいとしても Perl は多くの 選択肢を提供するからです。
Looking at it another way, writing portable code is usually about willfully limiting your available choices. Naturally, it takes discipline and sacrifice to do that. The product of portability and convenience may be a constant. You have been warned.
これを他の方法で見てみると、移植性のあるコードを書くことは通常あなたが 取り得る選択肢を故意に制限します。 当然ながら、これは規律と犠牲が伴います。 おそらく移植性と利便性の積は一定です。 あなたは警告されましたよ。
Be aware of two important points:
二つの重要な点に注意してください:
- Not all Perl programs have to be portable
-
(全ての Perl プログラムが移植性がある必要はありません)
There is no reason you should not use Perl as a language to glue Unix tools together, or to prototype a Macintosh application, or to manage the Windows registry. If it makes no sense to aim for portability for one reason or another in a given program, then don't bother.
Unix ツールを互いにくっつけたり、Macintosh アプリケーションのプロトタイプを 作ったり、Windows レジストリを操作するための言語として Perl を 使うべきではないという理由はありません。 プログラムにとって何らかの理由で移植性を目標とすることが無意味なら、 気にしないでください。
- Nearly all of Perl already is portable
-
(ほとんど全ての Perl は既に移植性が あります)
Don't be fooled into thinking that it is hard to create portable Perl code. It isn't. Perl tries its level-best to bridge the gaps between what's available on different platforms, and all the means available to use those features. Thus almost all Perl code runs on any machine without modification. But there are some significant issues in writing portable code, and this document is entirely about those issues.
移植性のある Perl コードを作るのが難しいという考えに騙されないでください。 そうではありません。 Perl は、異なったプラットフォームで何が利用可能かとこの機能を使うために 利用可能なもの全てとの間のずれを出来るだけ橋渡ししようとします。 従って、ほとんど全ての Perl コードは修正なしにどのマシンでも動作します。 しかし移植性のあるコードを書くにはいくつかの重要な問題があり、この文書は 全体的にそのような問題を扱っています。
Here's the general rule: When you approach a task commonly done using a whole range of platforms, think about writing portable code. That way, you don't sacrifice much by way of the implementation choices you can avail yourself of, and at the same time you can give your users lots of platform choices. On the other hand, when you have to take advantage of some unique feature of a particular platform, as is often the case with systems programming (whether for Unix, Windows, VMS, etc.), consider writing platform-specific code.
一般的なルールを挙げます: プラットフォーム全体で使われて一般的に 処理されるようなタスクに迫るとき、移植性のあるコードを書くことを 考えてください。 その方向で、自分自身の実装の選択肢を多く犠牲にすることはなく、 同時にユーザーに多くのプラットフォームの選択肢を与えることができます。 一方、特定のプラットフォームで固有の機能の利点を使う必要がある場合、 例えば (Unix, Windows, VMS など専用の) システムプログラムのような 場合、プラットフォーム固有のコードを書くことを考えてください。
When the code will run on only two or three operating systems, you may need to consider only the differences of those particular systems. The important thing is to decide where the code will run and to be deliberate in your decision.
コードが二つか三つのオペレーティングシステムでだけ動作するときは、 それらの特定のシステムでの違いのみを考慮する必要があります。 重要なことは、どこでコードを実行するかと、決定を熟考することです。
The material below is separated into three main sections: main issues of portability ("ISSUES"), platform-specific issues ("PLATFORMS"), and built-in Perl functions that behave differently on various ports ("FUNCTION IMPLEMENTATIONS").
以下の材料は三つの主な章に分割されています: 主な移植性の問題 ("ISSUES")、プラットフォーム固有の問題 ("PLATFORMS")、 OS によって異なった振る舞いをする Perl 組み込み関数 ("FUNCTION IMPLEMENTATIONS") です。
This information should not be considered complete; it includes possibly transient information about idiosyncrasies of some of the ports, almost all of which are in a state of constant evolution. Thus, this material should be considered a perpetual work in progress (<IMG SRC="yellow_sign.gif" ALT="Under Construction">).
この情報は完全であると考えるべきではありません; これは一部の OS に対する 特異性に関するおそらく一時的な情報を含んでいて、それらのほとんどは常に 進化しているものです。 従って、この材料は永遠に作業中であると考えるべきです (<IMG SRC="yellow_sign.gif" ALT="Under Construction">)。
問題¶
改行¶
In most operating systems, lines in files are terminated by newlines. Just what is used as a newline may vary from OS to OS. Unix traditionally uses \012, one type of DOSish I/O uses \015\012, Mac OS uses \015, and z/OS uses \025.
ほとんどのオペレーティングシステムで、ファイルの行は改行で終端されます。 単に改行として何を使うかが OS によって異なります。 Unix は伝統的に \012 を使い、DOS 風の I/O は \015\012 を使い、 Mac OS は \015 を使い、z/OS は \025 を使います。
Perl uses \n to represent the "logical" newline, where what is logical may depend on the platform in use. In MacPerl, \n always means \015. On EBCDIC platforms, \n could be \025 or \045. In DOSish perls, \n usually means \012, but when accessing a file in "text" mode, perl uses the :crlf layer that translates it to (or from) \015\012, depending on whether you're reading or writing. Unix does the same thing on ttys in canonical mode. \015\012 is commonly referred to as CRLF.
Perl は「論理的な」改行を表現するのに \n を使います; 何が論理的かは 使っているプラットフォームに依存しています。 MacPerl では \n は常に \015 を意味します。 EBCDIC プラットフォームでは、\n は \025 または \045 です。 DOS 風の perl では、\n は普通 \012 を意味しますが、ファイルを 「テキスト」モードでアクセスすると、perl は \015\012 との間で 変換する :crlf を使います。 Unix はカノニカルモードの tty で同じことをします。 \015\012 は一般的には CRLF として参照されます。
To trim trailing newlines from text lines use chomp. With default settings that function looks for a trailing \n character and thus trims in a portable way.
テキスト行から末尾の改行を切り落とすには、 chomp を使います。 この関数のデフォルト設定は末尾の \n 文字を探すので、移植性のある形で 切り落とします。
When dealing with binary files (or text files in binary mode) be sure to explicitly set $/ to the appropriate value for your file format before using chomp.
バイナリファイル (またはバイナリモードでのテキストファイル) を扱うときには、 chomp を使う前にファイル形式に適切な値を $/ に明示的に設定してください。
Because of the "text" mode translation, DOSish perls have limitations in using seek and tell on a file accessed in "text" mode. Stick to seek-ing to locations you got from tell (and no others), and you are usually free to use seek and tell even in "text" mode. Using seek or tell or other file operations may be non-portable. If you use binmode on a file, however, you can usually seek and tell with arbitrary values safely.
「テキスト」モード変換によって、DOS 的な perl は「テキスト」モードで アクセスするファイルに対する seek と tell の使用に制限があります。 tell で得た位置へ seek する(そして他の方法を 使わない)ことに専念することで、「テキスト」モードでも自由に seek と tell を使えます。 seek や tell やその他のファイル操作は互換性が ないかもしれません。 しかし、ファイルに対して binmode を使うと、普通は任意の値を seek と tell に使っても安全です。
A common misconception in socket programming is that \n eq \012 everywhere. When using protocols such as common Internet protocols, \012 and \015 are called for specifically, and the values of the logical \n and \r (carriage return) are not reliable.
ソケットプログラミングでのよくある誤解は、どこでも \n eq \012 であると いうものです。 一般的なインターネットプロトコルのようなプロトコルを使うとき、 \012 と \015 は明確に記述されていて、論理的な \n と \r (復帰) の値は信頼できません。
print $socket "Hi there, client!\r\n"; # WRONG
print $socket "Hi there, client!\015\012"; # RIGHTHowever, using \015\012 (or \cM\cJ, or \x0D\x0A) can be tedious and unsightly, as well as confusing to those maintaining the code. As such, the Socket module supplies the Right Thing for those who want it.
しかし、\015\012 (または \cM\cJ または \x0D\x0A) を使うのは 退屈で見苦しいかもしれませんし、コードの保守に混乱するかもしれません。 そのようなものとして、Socket モジュールは求められていることに 対する正しいものを供給します。
use Socket qw(:DEFAULT :crlf);
print $socket "Hi there, client!$CRLF" # RIGHTWhen reading from a socket, remember that the default input record separator $/ is \n, but robust socket code will recognize as either \012 or \015\012 as end of line:
ソケットから読み込むとき、デフォルト入力レコード区切り $/> は \n だけれども、 堅牢なソケットコードは \012 と \015\012 の どちらも行の末尾として認識することを忘れないでください:
while (<$socket>) { # NOT ADVISABLE!
# ...
}Because both CRLF and LF end in LF, the input record separator can be set to LF and any CR stripped later. Better to write:
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
}This example is preferred over the previous one--even for Unix platforms--because now any \015's (\cM's) are stripped out (and there was much rejoicing).
この例は -- 例え Unix プラットフォームでも -- 以前のものよりよいものです; なぜなら全ての \015 (\cM) が削除される(そしてこれはとても喜ばしい) からです。
Similarly, functions that return text data--such as a function that fetches a web page--should sometimes translate newlines before returning the data, if they've not yet been translated to the local newline representation. A single line of code will often suffice:
同様に、-- web ページを取得する関数のような -- テキストデータを返す関数は、 まだローカルな改行表現に変換されていないなら、データを返す前に改行を 変換するべき場合もあります。 しばしば 1 行のコードで十分です:
$data =~ s/\015?\012/\n/g;
return $data;Some of this may be confusing. Here's a handy reference to the ASCII CR and LF characters. You can print it out and stick it in your wallet.
これらには混乱があるかもしれません。 以下は 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 STDIOThe Unix column assumes that you are not accessing a serial line (like a tty) in canonical mode. If you are, then CR on input becomes "\n", and "\n" on output becomes CRLF.
Unix の列は、カノニカルモードで(tty のような)シリアルインターフェースに アクセスしているのではないことを仮定しています。 もしそうなら、入力の CR は "\n" になり、出力の "\n" は CRLF になります。
These are just the most common definitions of \n and \r in Perl. There may well be others. For example, on an EBCDIC implementation such as z/OS (OS/390) or OS/400 (using the ILE, the PASE is ASCII-based) the above material is similar to "Unix" but the code numbers change:
これらは単に 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数値のエンディアンと幅¶
Different CPUs store integers and floating point numbers in different orders (called endianness) and widths (32-bit and 64-bit being the most common today). This affects your programs when they attempt to transfer numbers in binary format from one CPU architecture to another, usually either "live" via network connection, or by storing the numbers to secondary storage such as a disk file or tape.
CPU が異なると、整数と浮動小数点数の順序 (エンディアン (endianness) と 呼ばれます) と幅 (最近ではほとんど 32 ビットと 64 ビットです) が異なります。 これは、ある CPU アーキテクチャから他のものへ数値をバイナリ形式で、 普通はネットワーク接続経由で「ライブ」で、またはディスクファイルや テープのような二次ストレージに保管することで移そうとしたときに 影響します。
Conflicting storage orders make an utter mess out of the numbers. If a little-endian host (Intel, VAX) stores 0x12345678 (305419896 in decimal), a big-endian host (Motorola, Sparc, PA) reads it as 0x78563412 (2018915346 in decimal). Alpha and MIPS can be either: Digital/Compaq used/uses them in little-endian mode; SGI/Cray uses them in big-endian mode. To avoid this problem in network (socket) connections use the pack and unpack formats n and N, the "network" orders. These are guaranteed to be portable.
保管の順序が衝突すると値が完全におかしくなります。 リトルエンディアンのホスト (Intel, VAX) が 0x12345678 (10 進数では 305419896) を保管すると、ビッグエンディアンのホスト (Motorola, Sparc, PA) は これを 0x78563412 (10 進数では 2018915346) として読み込みます。 Alpha と MIPS はどちらもあり得ます: Digital/Compaq はこれを リトルエンティアンモードで使います; SGI/Cray はこれを ビッグエンディアンモードで使います。 ネットワーク(ソケット)接続でこの問題を避けるには、 pack と unpack の 「ネットワーク」順序フォーマットである n および N を使ってください。 これらは移植性があることを保証します。
As of Perl 5.10.0, you can also use the > and < modifiers to force big- or little-endian byte-order. This is useful if you want to store signed integers or 64-bit integers, for example.
Perl 5.10.0 から、ビッグエンディアンとリトルエンディアンにバイト順を 強制するための > と < の修飾子も使えます。 これは例えば、符号付き整数や 64 ビット整数を保管したいときに有用です。
You can explore the endianness of your platform by unpacking a data structure packed in native format such as:
次のように、ネイティブな形式で 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 68040If you need to distinguish between endian architectures you could use either of the variables set like so:
エンディアンアーキテクチャを区別する必要があるなら、以下のような変数の どちらかを使えます:
$is_big_endian = unpack("h*", pack("s", 1)) =~ /01/;
$is_little_endian = unpack("h*", pack("s", 1)) =~ /^1/;Differing widths can cause truncation even between platforms of equal endianness. The platform of shorter width loses the upper parts of the number. There is no good solution for this problem except to avoid transferring or storing raw binary numbers.
幅の違いは同じエンディアンのプラットフォームの間でも切り詰めを 引き起こすことがあります。 幅がより短い側のプラットフォームは数値の上位部分を失います。 生のバイナリ数値を転送したり保管したりしないようにする以外に、この問題への よい解決法はありません。
One can circumnavigate both these problems in two ways. Either transfer and store numbers always in text format, instead of raw binary, or else consider using modules like Data::Dumper and Storable (included as of Perl 5.8). Keeping all data as text significantly simplifies matters.
これらの問題は二つの方法で避けることが出来ます。 数値を常に生のバイナリではなくテキスト形式で転送して保管するか、(Perl 5.8 から含まれている) Data::Dumper や Storable のようなモジュールを使うことを考慮してください。 全てのデータをテキストで扱うことは問題をかなり単純化します。
ファイルとファイルシステム¶
Most platforms these days structure files in a hierarchical fashion. So, it is reasonably safe to assume that all platforms support the notion of a "path" to uniquely identify a file on the system. How that path is really written, though, differs considerably.
最近のほとんどのプラットフォームではファイルの構造は階層的です。 従って、全てのプラットフォームがシステム中のファイルをユニークに 識別するための「パス」記法に対応していると仮定することは合理的に安全です。 パスが実際にどのように書かれるかはかなり異なります。
Although similar, file path specifications differ between Unix, Windows, Mac OS, OS/2, VMS, VOS, RISC OS, and probably others. Unix, for example, is one of the few OSes that has the elegant idea of a single root directory.
似てはいるものの、ファイルパスの指定方法は Unix, Windows, Mac OS, OS/2, VMS, VOS, RISC OS そしておそらくその他で 異なります。 例えば、Unix は一つのルートディレクトリというエレガントな考え方を持つ 数少ない OS の一つです。
DOS, OS/2, VMS, VOS, and Windows can work similarly to Unix with / as path separator, or in their own idiosyncratic ways (such as having several root directories and various "unrooted" device files such NIL: and LPT:).
DOS, OS/2, VMS, VOS, Windows は / をパス区切りとして、(複数の ルートディレクトリや、NIL: や LPT: のような様々な「ルートでない」 デバイスファイルといった)独自の風変わりな方法で Unix と似たように 動作します。
Mac OS 9 and earlier used : as a path separator instead of /.
Mac OS 9 以前はパス区切りに / ではなく : を使います。
ファイルシステムはハードリンク (link) やシンボリックリンク (symlink, readlink, lstat) に対応していないかもしれません。
The filesystem may support neither access timestamp nor change timestamp (meaning that about the only portable timestamp is the modification timestamp), or one second granularity of any timestamps (e.g. the FAT filesystem limits the time granularity to two seconds).
ファイルシステムはアクセスタイムスタンプや変更タイムスタンプに 対応していないかもしれません (つまり移植性のあるタイムスタンプは 変更タイムスタンプだけです); またタイムスタンプは 1 秒単位では ないかもしれません (例えば、FAT ファイルシステムは時刻の単位は 2 秒単位です)。
The "inode change timestamp" (the -C filetest) may really be the "creation timestamp" (which it is not in Unix).
「inode 変更タイムスタンプ」 (-C ファイルテスト) は (Unix 以外では) 実際には「作成タイムスタンプ」かもしれません。
VOS perl can emulate Unix filenames with / as path separator. The native pathname characters greater-than, less-than, number-sign, and percent-sign are always accepted.
VOS perl は / をパス区切りとして Unix ファイル名をエミュレートできます。 ネイティブなパス名文字である大なり、小なり、シャープ、パーセントは常に 受け入れられます。
RISC OS perl can emulate Unix filenames with / as path separator, or go native and use . for path separator and : to signal filesystems and disk names.
RISC OS perl は / をパス区切りとして Unix ファイル名をエミュレート するか、ネイティブのままで . をパス区切り、: をファイルシステムと ディスクの名前として使えます。
Don't assume Unix filesystem access semantics: that read, write, and execute are all the permissions there are, and even if they exist, that their semantics (for example what do r, w, and x mean on a directory) are the Unix ones. The various Unix/POSIX compatibility layers usually try to make interfaces like chmod work, but sometimes there simply is no good mapping.
Unix のファイルシステムアクセスの意味を仮定しないで下さい: 読み込み、 書き込み、実行のどれもです; たとえあったとしても、その意味論 (例えばディレクトリに対して r, w, x が何をするか) は Unix のものです。 様々な Unix/POSIX 互換層は普通 chmod のようなものが動作するための インターフェースとなっていますが、ときどき単にいいマッピングが ないこともあります。
The File::Spec modules provide methods to manipulate path specifications and return the results in native format for each platform. This is often unnecessary as Unix-style paths are understood by Perl on every supported platform, but if you need to produce native paths for a native utility that does not understand Unix syntax, or if you are operating on paths or path components in unknown (and thus possibly native) syntax, File::Spec is your friend. Here are two brief examples:
File::Spec モジュールはパス仕様を操作し、各プラットフォームに ネイティブな型式での結果を返します。 Perl は全ての対応しているプラットフォームで Unix 型式のパスを理解するので これはしばしば不要でが、Unix 文法を理解しないネイティブな ユーティリティのためにネイティブなパスを生成する必要がある場合や、 不明な(従っておそらくネイティブな)文法のパスやパス要素を操作する場合に、 File::Spec が役に立ちます。 次の二つは概要の例です:
use File::Spec::Functions;
chdir(updir()); # go up one directory
# Concatenate a path from its components
my $file = catfile(updir(), 'temp', 'file.txt');
# on Unix: '../temp/file.txt'
# on Win32: '..\temp\file.txt'
# on VMS: '[-.temp]file.txt'In general, production code should not have file paths hardcoded. Making them user-supplied or read from a configuration file is better, keeping in mind that file path syntax varies on different machines.
一般的に、製品コードはファイルパスをハードコーディングするべきでは ありません。 ユーザーが指定できるようにするか、設定ファイルから読み込む方がよいです; ファイルパスの文法はマシンによって異なることを忘れないでください。
This is especially noticeable in scripts like Makefiles and test suites, which often assume / as a path separator for subdirectories.
これは、しばしば / がサブディレクトリのパス区切りと仮定されている Makefile やテストスイートのようなスクリプトで特に注意が必要です。
Also of use is File::Basename from the standard distribution, which splits a pathname into pieces (base filename, full path to directory, and file suffix).
もう一つの有用なものは標準配布に含まれている File::Basename で、これはパス名をベースファイル名、 ディレクトリのフルパス、ファイルの拡張子に分解します。
Even when on a single platform (if you can call Unix a single platform), remember not to count on the existence or the contents of particular system-specific files or directories, like /etc/passwd, /etc/sendmail.conf, /etc/resolv.conf, or even /tmp/. For example, /etc/passwd may exist but not contain the encrypted passwords, because the system is using some form of enhanced security. Or it may not contain all the accounts, because the system is using NIS. If code does need to rely on such a file, include a description of the file and its format in the code's documentation, then make it easy for the user to override the default location of the file.
単一のプラットフォームでさえ(Unix を単一のプラットフォームと呼ぶなら)、 /etc/passwd, /etc/sendmail.conf, /etc/resolv.conf あるいは /tmp/ でさえ、特定のシステム固有のファイルやディレクトリの存在や その内容を当てにできないことを忘れないでください。 例えば、/etc/passwd は存在するかもしれませんが、システムがある種の 強化されたセキュリティを使っているために、暗号化されたパスワードを 含んでいないかもしれません。 あるいは、NIS を使っているために、全てのアカウントを 含んでいないかもしれません。 コードがこのようなファイルに依存する必要がある場合、コードの文書に ファイルの説明とその形式を含めて、ユーザーがファイルのデフォルトの位置を 簡単に上書きできるようにします。
Don't assume a text file will end with a newline. They should, but people forget.
テキストファイルが改行で終わっていると仮定しないでください。 そうあるべきですが、人は忘れます。
Do not have two files or directories of the same name with different case, like test.pl and Test.pl, as many platforms have case-insensitive (or at least case-forgiving) filenames. Also, try not to have non-word characters (except for .) in the names, and keep them to the 8.3 convention, for maximum portability, onerous a burden though this may appear.
test.pl と Test.pl のような、大文字と小文字が違うだけの名前の二つの ファイルやディレクトリを作らないでください; 多くのプラットフォームは 大文字小文字を無視する(あるいは少なくとも大文字小文字に寛容な) ファイル名を持つからです。 また、最大限の互換性のため、起きるかも知れない厄介事のために、 (. 以外の)非単語文字を使わないようにして、8.3 の規約を維持してください。
Likewise, when using the AutoSplit module, try to keep your functions to 8.3 naming and case-insensitive conventions; or, at the least, make it so the resulting files have a unique (case-insensitively) first 8 characters.
同様に、AutoSplit モジュールを使う場合、関数の 8.3 の命名と 大文字小文字を無視する規約を維持するようにしてください; あるいは、少なくとも、 結果のファイルが最初の 8 文字が(大文字小文字を無視して)ユニークに なるようにしてください。
Whitespace in filenames is tolerated on most systems, but not all, and even on systems where it might be tolerated, some utilities might become confused by such whitespace.
ファイル名の空白はほとんどのシステムで許容されますが、全てではなく、 許容しているシステムでも、そのような空白によって混乱するユーティリティも あります。
Many systems (DOS, VMS ODS-2) cannot have more than one . in their filenames.
多くのシステム (DOS, VMS ODS-2) はファイル名に二つ以上の . を 使えません。
Don't assume > won't be the first character of a filename. Always use the three-arg version of open:
> がファイル名の最初の文字ではないと仮定しないでください。 常に 3 引数版の open を 使ってください:
open my $fh, '<', $existing_file) or die $!;Two-arg open is magic and can translate characters like >, <, and | in filenames, which is usually the wrong thing to do. sysopen and three-arg open don't have this problem.
2 引数の open はマジカルで、 ファイル名の >, <, | のような文字を 変換することがあり、これは普通は間違ったことです。 sysopen と 3 引数形式の open はこの問題がありません。
Don't use : as a part of a filename since many systems use that for their own semantics (Mac OS Classic for separating pathname components, many networking schemes and utilities for separating the nodename and the pathname, and so on). For the same reasons, avoid @, ; and |.
: をファイル名の一部として使わないでください; 多くのシステムがこれを 独自の意味で使っているからです (Mac OS Classic はパス名要素を分割するために、 多くのネットワークスキームとユーティリティではノード名とパス名を 分割するために、など)。 同じ理由で、@, ;, | も避けてください。
Don't assume that in pathnames you can collapse two leading slashes // into one: some networking and clustering filesystems have special semantics for that. Let the operating system sort it out.
パス名の先頭の二つのスラッシュ // を一つに圧縮できると 仮定しないでください: ある種のネットワーキングとクラスタリングの ファイルシステムはこれに対して特別な意味論を持ちます。 オペレーティングシステムに任せてください。
The portable filename characters as defined by ANSI C are
ANSI C で定義されている、移植性のあるファイル名の文字 は:
a b c d e f g h i j k l m n o p q r s 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 S T U V W X Y Z
0 1 2 3 4 5 6 7 8 9
. _ -and - shouldn't be the first character. If you want to be hypercorrect, stay case-insensitive and within the 8.3 naming convention (all the files and directories have to be unique within one directory if their names are lowercased and truncated to eight characters before the ., if any, and to three characters after the ., if any). (And do not use .s in directory names.)
かつ - は最初の文字には使えません。 もし超完全にしたいなら、大文字小文字は無視して、8.3 命名規約に従います (全てのファイルとディレクトリは、名前を小文字にして、(もしあれば) . の 前の 8 文字と (もしあれば) . の後の 3 文字に切り詰めたときに、 ディレクトリ内でユニークである必要があります)。 (そしてディレクトリ名に . を使わないでください。)
システムの相互作用¶
Not all platforms provide a command line. These are usually platforms that rely primarily on a Graphical User Interface (GUI) for user interaction. A program requiring a command line interface might not work everywhere. This is probably for the user of the program to deal with, so don't stay up late worrying about it.
全てのプラットフォームがコマンドラインを提供しているわけではありません。 これらは普通ユーザーとの相互作用にグラフィカルユーザーインターフェース (GUI) に基本的に依存しています。 コマンドラインインターフェースを要求するプログラムはどこでも 動作するわけではありません。 これはおそらくプログラムを扱うユーザーの問題なので、心配して遅くまで 起きていないでください。
Some platforms can't delete or rename files held open by the system, this limitation may also apply to changing filesystem metainformation like file permissions or owners. Remember to close files when you are done with them. Don't unlink or rename an open file. Don't tie or open a file already tied or opened; untie or close it first.
一部のプラットフォームはシステムによって開かれているファイルを削除または リネームできません; この制限はファイル権限や所有者のような ファイルシステムのメタ情報の変更にも適用されることもあります。 ファイルに対する作業が終わったら、 close することを忘れないでください。 開いているファイルに対して unlink または rename しないでください。 すでに tie されていたり開かれていたりするファイルに対して tie や open をしないで下さい; まず untie または close してください。
Don't open the same file more than once at a time for writing, as some operating systems put mandatory locks on such files.
同じファイルを同時に 2 回以上書き込みのために開いてはいけません; 一部のオペレーティングシステムはそのようなファイルに排他的ロックを掛けます。
Don't assume that write/modify permission on a directory gives the right to add or delete files/directories in that directory. That is filesystem specific: in some filesystems you need write/modify permission also (or even just) in the file/directory itself. In some filesystems (AFS, DFS) the permission to add/delete directory entries is a completely separate permission.
ディレクトリへの書き込み/修正権限があれば、そのディレクトリにある ファイル/ディレクトリを追加または削除できると仮定しないでください。 これはファイルシステム依存です: そのファイル/ディレクトリ自身の 書き込み/修正権限も(あるいはそれだけが)必要なファイルシステムもあります。 一部のファイルシステム (AFS, DFS) では、ディレクトリ要素の追加/削除権限は 完全に別の権限です。
Don't assume that a single unlink completely gets rid of the file: some filesystems (most notably the ones in VMS) have versioned filesystems, and unlink removes only the most recent one (it doesn't remove all the versions because by default the native tools on those platforms remove just the most recent version, too). The portable idiom to remove all the versions of a file is
1 回の unlink で完全にファイルを取り除けると 仮定しないでください: 一部のファイルシステム (もっとも顕著なものは VMS) はバージョン管理された ファイルシステムを持ち、 unlink は単に最新のものだけを削除します (デフォルトではネイティブなツールも単に最新のバージョンを削除するので、 全てのバージョンは削除しません)。 あるファイルの全てのバージョンを削除するための移植性のある慣用句は:
1 while unlink "file";This will terminate if the file is undeletable for some reason (protected, not there, and so on).
これは (保護されている、存在しない、など) 何らかの理由でファイルが 削除できないときに終了します。
Don't count on a specific environment variable existing in %ENV. Don't count on %ENV entries being case-sensitive, or even case-preserving. Don't try to clear %ENV by saying %ENV = ();, or, if you really have to, make it conditional on $^O ne 'VMS' since in VMS the %ENV table is much more than a per-process key-value string table.
特定の環境変数が %ENV にあるということを計算に入れないでください。 %ENV のエントリが大文字小文字を認識するかや、大文字小文字が 保存されるかすらも計算に入れないでください。 %ENV をクリアするために %ENV = (); としないでください; もし 本当にそうする必要があるなら、$^O ne 'VMS' という条件付きで 行ってください; VMS では %ENV テーブルはプロセス単位のキー/値文字列 テーブル以上のものだからです。
On VMS, some entries in the %ENV hash are dynamically created when their key is used on a read if they did not previously exist. The values for $ENV{HOME}, $ENV{TERM}, $ENV{PATH}, and $ENV{USER}, are known to be dynamically generated. The specific names that are dynamically generated may vary with the version of the C library on VMS, and more may exist than are documented.
VMS では、%ENV ハッシュの一部のエントリは、キーがまだ存在していなければ、 読み込みに使われたときに動的に作成されます。 $ENV{HOME}, $ENV{TERM}, $ENV{PATH}, and $ENV{USER} の値は 動的に作成されると知られています。 動的に作成される具体的な名前は VMS の C ライブラリのバージョンによって 異なり、文書化されているものよりもたくさんあるかもしれません。
On VMS by default, changes to the %ENV hash persist after perl exits. Subsequent invocations of perl in the same process can inadvertently inherit environment settings that were meant to be temporary.
VMS のデフォルトでは、%ENV ハッシュへの変更は、perl が 終了した後に永続化します。 同じプロセスで引き続いて perl を起動すると、一時的のつもりの環境設定が 不注意で継承されることがあります。
Don't count on signals or %SIG for anything.
シグナルや %SIG について何も当てにしないで下さい。
ファイル名のグロブを当てにしないで下さい。 代わりに opendir, readdir, closedir を使ってください。
Don't count on per-program environment variables, or per-program current directories.
プログラム単位の環境変数や、プログラム単位のカレントディレクトリを 当てにしないで下さい。
Don't count on specific values of $!, neither numeric nor especially the string values. Users may switch their locales causing error messages to be translated into their languages. If you can trust a POSIXish environment, you can portably use the symbols defined by the Errno module, like ENOENT. And don't trust on the values of $! at all except immediately after a failed system call.
$! の特定の値を計算に入れないでください; 数値でも、 特に文字列値でもです。 ユーザーは自分の言語へ翻訳するためにエラーメッセージを引き起こす ロケールを変更するかもしれません。 もし POSIX 的な環境を信用できるなら、ENOENT のような、 Errno モジュールで定義されているシンボルを移植性を持って使えます。 そして、システムコールが失敗した直後以外では $! の値は一切信用しないでください。
コマンド名かファイルパス名か¶
Don't assume that the name used to invoke a command or program with system or exec can also be used to test for the existence of the file that holds the executable code for that command or program. First, many systems have "internal" commands that are built-in to the shell or OS and while these commands can be invoked, there is no corresponding file. Second, some operating systems (e.g., Cygwin, OS/2, and VOS) have required suffixes for executable files; these suffixes are generally permitted on the command name but are not required. Thus, a command like perl might exist in a file named perl, perl.exe, or perl.pm, depending on the operating system. The variable $Config{_exe} in the Config module holds the executable suffix, if any. Third, the VMS port carefully sets up $^X and $Config{perlpath} so that no further processing is required. This is just as well, because the matching regular expression used below would then have to deal with a possible trailing version number in the VMS file name.
system や exec で コマンドやプログラムを起動するために使われた名前が、 そのコマンドやプログラムの実行可能コードを保持しているファイルの存在の テストにも使えると仮定しないでください。 1 番目に、多くのシステムはシェルや OS に組み込まれている「内部」コマンドを 持ち、これらのコマンドは起動できますが、対応するファイルはありません。 2 番目に、一部のオペレーティングシステム(例えば Cygwin, OS/2, VOS) は 実行ファイルに拡張子が必要です; これらの拡張子は一般的にコマンド名として ゆるされていますが要求されてはいません。 従って、perl のようなコマンドは OS に依存して、perl, perl.exe, perl.pm のようなファイルとして存在しているかもしれません。 Config モジュールの変数 $Config{_exe} は、 (もしあれば)実行形式の拡張子を保持します。 3 番目に、VMS 版はそれ以上の処理が不要なように慎重に $^X と $Config{perlpath} を設定します。 これは、以下に示す正規表現のマッチングがそれから VMS ファイル名に あるかもしれない末尾のバージョン番号を扱う必要があるからです。
To convert $^X to a file pathname, taking account of the requirements of the various operating system possibilities, say:
$^X をファイルパス名に変換するとき、以下のように、様々な オペレーティングシステムの可能性の要求を考慮してください:
use Config;
my $thisperl = $^X;
if ($^O ne 'VMS') {
$thisperl .= $Config{_exe}
unless $thisperl =~ m/\Q$Config{_exe}\E$/i;
}To convert $Config{perlpath} to a file pathname, say:
$Config{perlpath} をファイルのパス名に変換するには、 例えば:
use Config;
my $thisperl = $Config{perlpath};
if ($^O ne 'VMS') {
$thisperl .= $Config{_exe}
unless $thisperl =~ m/\Q$Config{_exe}\E$/i;
}ネットワーク¶
Don't assume that you can reach the public Internet.
公共のインターネットに届くことを仮定しないでください。
Don't assume that there is only one way to get through firewalls to the public Internet.
ファイアウォールを通って公共のインターネットへ出る道が 一つだけあるということを仮定しないでください。
Don't assume that you can reach outside world through any other port than 80, or some web proxy. ftp is blocked by many firewalls.
ポート 80 やいくつかのウェブプロキシ以外で、外側の世界に届くことを 仮定しないでください。 ftp は多くのファイアウォールでブロックされます。
Don't assume that you can send email by connecting to the local SMTP port.
ローカル SMTP ポートに接続することで e メールを送信できると 仮定しないでください。
Don't assume that you can reach yourself or any node by the name 'localhost'. The same goes for '127.0.0.1'. You will have to try both.
'localhost' という名前で自分自身やその他のノードに届くと 仮定しないでください。 同じことは '127.0.0.1' にも言えます。 両方を試す必要があります。
Don't assume that the host has only one network card, or that it can't bind to many virtual IP addresses.
ホストに 1 枚だけネットワークカードがあるとか、複数の仮想 IP アドレスを 割り当てられないと仮定しないでください。
Don't assume a particular network device name.
特定のネットワークデバイス名を仮定しないでください。
Don't assume a particular set of ioctls will work.
特定の ioctl が 動作することを仮定しないでください。
Don't assume that you can ping hosts and get replies.
ホストに ping して結果が受け取れると仮定しないでください。
Don't assume that any particular port (service) will respond.
特定のポート (サービス) が返答すると仮定しないでください。
Don't assume that Sys::Hostname (or any other API or command) returns either a fully qualified hostname or a non-qualified hostname: it all depends on how the system had been configured. Also remember that for things such as DHCP and NAT, the hostname you get back might not be very useful.
Sys::Hostname (またはその他の API やコマンド) が 完全修飾ホスト名か修飾されないホスト名のどちらかを返すと仮定しないでください: これら全てはシステムがどのように設定されているかに依存します。 また、DHCP や NAT のようなものでは、受け取るホスト名は全く 有用ではないかもしれないことも忘れないでください。
All the above don'ts may look daunting, and they are, but the key is to degrade gracefully if one cannot reach the particular network service one wants. Croaking or hanging do not look very professional.
上述した全ての べからず は怯えさせるものかもしれません; そしてその 通りです; しかし鍵は、望んでいる特定のネットワークサービスに 到達できないときに、適切にデグレードすることです。 croak やハングアップではとてもプロの仕事には見えません。
プロセス間通信(IPC)¶
In general, don't directly access the system in code meant to be portable. That means, no system, exec, fork, pipe, `` or qx//, open with a |, nor any of the other things that makes being a Perl hacker worth being.
一般的に、移植性を持たせるコード内でシステムに直接アクセスしないでください。 つまり、 system, exec, fork, pipe, `` or qx//, open での |、その他 Perl ハッカーが価値があると思うものです。
Commands that launch external processes are generally supported on most platforms (though many of them do not support any type of forking). The problem with using them arises from what you invoke them on. External tools are often named differently on different platforms, may not be available in the same location, might accept different arguments, can behave differently, and often present their results in a platform-dependent way. Thus, you should seldom depend on them to produce consistent results. (Then again, if you're calling netstat -a, you probably don't expect it to run on both Unix and CP/M.)
外部プロセスを起動するコマンドは一般的にほとんどのプラットフォームで 対応しています(しかしその多くは fork に対応していません)。 これらを使うときの問題は何を起動するかということから発生します。 外部ツールはプラットフォームが異なればしばしば異なった名前となり、 同じ場所で利用可能ではないかもしれず、異なった引数を受け取るかもしれず、 異なった動作をするかもしれず、しばしば結果をプラットフォームに依存した形で 表現します。 従って、一貫した結果を生成するために、ほとんどそのようなものに 依存しないようにするべきです。 (再び、netstat -a を呼び出すなら、おそらく Unix と CP/M の両方で 呼び出すことを想定していないでしょう。)
One especially common bit of Perl code is opening a pipe to sendmail:
特に一般的な Perl コードの一つは sendmail へのパイプを開くことです:
open(my $mail, '|-', '/usr/lib/sendmail -t')
or die "cannot fork sendmail: $!";This is fine for systems programming when sendmail is known to be available. But it is not fine for many non-Unix systems, and even some Unix systems that may not have sendmail installed. If a portable solution is needed, see the various distributions on CPAN that deal with it. Mail::Mailer and Mail::Send in the MailTools distribution are commonly used, and provide several mailing methods, including mail, sendmail, and direct SMTP (via Net::SMTP) if a mail transfer agent is not available. Mail::Sendmail is a standalone module that provides simple, platform-independent mailing.
sendmail が利用可能であることが分かっているならシステム プログラミングとしてうまく動きます。 しかし多くの非 Unix システムや、Unix でも sendmail が インストールされていないシステムではうまく動きません。 移植性のある解法が必要なら、CPAN にあるこれを扱うための様々な ディストリビューションを参照してください。 Mail::Mailer および MailTools の Mail::Send は一般的に使われ、mail、 sendmail、メール転送エージェントが利用できないなら (Net::SMTP 経由で) SMTP 直接を含むいくつかのメール送信メソッドを提供します。 Mail::Sendmail は単純で、プラットフォーム独立なメール送信を提供する 単体のモジュールです。
The Unix System V IPC (msg*(), sem*(), shm*()) is not available even on all Unix platforms.
Unix System V IPC (msg*(), sem*(), shm*()) は Unix プラットフォームでさえも全てで利用できるわけではありません。
Do not use either the bare result of pack("N", 10, 20, 30, 40) or bare v-strings (such as v10.20.30.40) to represent IPv4 addresses: both forms just pack the four bytes into network order. That this would be equal to the C language in_addr struct (which is what the socket code internally uses) is not guaranteed. To be portable use the routines of the Socket module, such as inet_aton, inet_ntoa, and sockaddr_in.
IPv4 アドレスを表現するために pack("N", 10, 20, 30, 40) の生の結果や (v10.20.30.40 のような)生のv-文字列を使わないでください: どちらの 形式も単に 4 バイトをネットワーク順序で pack しています。 これが(ソケットコードが内部で使う) C 言語の in_addr 構造体と 同じであることは保証されていません。 移植性を持たせるためには、 inet_aton, inet_ntoa, sockaddr_in のような、Socket モジュールのルーチンを 使ってください。
The rule of thumb for portable code is: Do it all in portable Perl, or use a module (that may internally implement it with platform-specific code, but exposes a common interface).
移植性のあるコードのための経験的な法則は: 全て移植性のある Perl でするか、 モジュールを使ってください (これは内部でプラットフォーム依存の実装を しているかもしれませんが、一般的なインターフェースを晒しています)。
外部サブルーチン(XS)¶
XS code can usually be made to work with any platform, but dependent libraries, header files, etc., might not be readily available or portable, or the XS code itself might be platform-specific, just as Perl code might be. If the libraries and headers are portable, then it is normally reasonable to make sure the XS code is portable, too.
XS コードは普通どのプラットフォームでも動作するように作られていますが、 依存ライブラリ、ヘッダファイルなどが利用可能でなかったり移植性がなかったり、 XS コード自身が (Perl コードがそうであるかもしれないように) プラットフォーム依存かもしれません。 ライブラリとヘッダに移植性があるなら、XS コードも移植性があると 考えるのは普通合理的です。
A different type of portability issue arises when writing XS code: availability of a C compiler on the end-user's system. C brings with it its own portability issues, and writing XS code will expose you to some of those. Writing purely in Perl is an easier way to achieve portability.
XS コードを書くときには違った種類の移植性の問題が発生します: エンドユーザーのシステムで C コンパイラが利用できるかです。 C はそれ自身の移植性の問題があり、XS コードはそれらのいくつかを晒します。 ピュア Perl で書くことは移植性を達成するより簡単な方法です。
標準モジュール¶
In general, the standard modules work across platforms. Notable exceptions are the CPAN module (which currently makes connections to external programs that may not be available), platform-specific modules (like ExtUtils::MM_VMS), and DBM modules.
一般的に、標準モジュールはどのプラットフォームでも動きます。 注目するべき例外は CPAN モジュール (今のところ 利用可能でないかもしれない外部プログラムと接続します)、 (ExtUtils::MM_VMS のような) プラットフォーム固有のモジュール、DBM モジュールです。
There is no one DBM module available on all platforms. SDBM_File and the others are generally available on all Unix and DOSish ports, but not in MacPerl, where only NDBM_File and DB_File are available.
全てのプラットフォームで利用可能な DBM モジュールはありません。 SDBM_File とその他は一般的に全ての Unix と DOS 風版で 利用可能ですが、MacPerl では利用できず、NDBM_File と DB_File のみが利用可能です。
The good news is that at least some DBM module should be available, and AnyDBM_File will use whichever module it can find. Of course, then the code needs to be fairly strict, dropping to the greatest common factor (e.g., not exceeding 1K for each record), so that it will work with any DBM module. See AnyDBM_File for more details.
いい知らせは、少なくとも何らかの DBM モジュールは利用可能なはずで、 AnyDBM_File は見付かったどれかのモジュールを使います。 もちろん、任意の DBM モジュールで動作させるために、コードはかなり厳密で、 最大公約数的機能に限定されます(例えば、各レコードは 1K を超えられません)。 さらなる詳細については AnyDBM_File を参照してください。
時刻と日付¶
The system's notion of time of day and calendar date is controlled in widely different ways. Don't assume the timezone is stored in $ENV{TZ}, and even if it is, don't assume that you can control the timezone through that variable. Don't assume anything about the three-letter timezone abbreviations (for example that MST would be the Mountain Standard Time, it's been known to stand for Moscow Standard Time). If you need to use timezones, express them in some unambiguous format like the exact number of minutes offset from UTC, or the POSIX timezone format.
カレンダー日付と時刻のシステムでの記法は大きく異なった方法で 制御されています。 タイムゾーンが $ENV{TZ} に保管されていると仮定しないでください; また例え保管されていても、この変数でタイムゾーンを制御できると 仮定しないでください。 3 文字タイムゾーン略称について何の仮定もしないで下さい (例えば MST は Mountain Standard Time かもしれませんが、Moscow Standard Time としても 知られています)。 タイムゾーンを使う必要があるなら、UTC からの正確な分数や POSIX タイムゾーン形式のような、曖昧さのない形式で記述してしてください。
Don't assume that the epoch starts at 00:00:00, January 1, 1970, because that is OS- and implementation-specific. It is better to store a date in an unambiguous representation. The ISO 8601 standard defines YYYY-MM-DD as the date format, or YYYY-MM-DDTHH:MM:SS (that's a literal "T" separating the date from the time). Please do use the ISO 8601 instead of making us guess what date 02/03/04 might be. ISO 8601 even sorts nicely as-is. A text representation (like "1987-12-18") can be easily converted into an OS-specific value using a module like Time::Piece (see "Date Parsing" in Time::Piece) or Date::Parse. An array of values, such as those returned by localtime, can be converted to an OS-specific representation using Time::Local.
紀元が 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" のような) テキスト表現は Time::Piece ("Date Parsing" in Time::Piece を参照してください) や Date::Parse のようなモジュールを 使って簡単に OS 固有の値に変換できます。 localtime で返されるような値の配列は、 Time::Local を使って OS 固有の表現に変換できます。
When calculating specific times, such as for tests in time or date modules, it may be appropriate to calculate an offset for the epoch.
時刻と日付のモジュールのテストのような、特定の時刻を計算するときには、 紀元からのオフセットを計算するのが適切でしょう。
use Time::Local qw(timegm);
my $offset = timegm(0, 0, 0, 1, 0, 1970);The value for $offset in Unix will be 0, but in Mac OS Classic will be some large number. $offset can then be added to a Unix time value to get what should be the proper value on any system.
Unix での $offset の値は 0 ですが、Mac OS Classic では 大きな数になります。 それから、$offset は任意のシステムでの適切な値を得るために Unix time に加えられます。
文字集合と文字エンコーディング¶
Assume very little about character sets.
文字集合について仮定できることはほとんどありません。
Assume nothing about numerical values (ord, chr) of characters. Do not use explicit code point ranges (like \xHH-\xHH). However, starting in Perl v5.22, regular expression pattern bracketed character class ranges specified like qr/[\N{U+HH}-\N{U+HH}]/ are portable, and starting in Perl v5.24, the same ranges are portable in tr///. You can portably use symbolic character classes like [:print:].
文字の数値 (ord, chr) について仮定できることはありません。 (\xHH-\xHH のような) 明示的な符号位置の範囲は使わないでください。 しかし、Perl v5.22 から、qr/[\N{U+HH}-\N{U+HH}]/ のように指定した 正規表現パターン大括弧文字クラス範囲は移植性があり、 Perl 5.24 から、同じ範囲は tr/// でも 移植性があります。 移植性のある形で [:print:] のようなシンボリックな文字クラスを使えます。
Do not assume that the alphabetic characters are encoded contiguously (in the numeric sense). There may be gaps. Special coding in Perl, however, guarantees that all subsets of qr/[A-Z]/, qr/[a-z]/, and qr/[0-9]/ behave as expected. tr/// behaves the same for these ranges. In patterns, any ranges specified with end points using the \N{...} notations ensures character set portability, but it is a bug in Perl v5.22 that this isn't true of tr///, fixed in v5.24.
英字が(数値的な意味で)連続してエンコードされると仮定しないでください。 隙間があるかもしれません。 しかし、Perl での特別扱いにより、qr/[A-Z]/, qr/[a-z]/, qr/[0-9]/ という部分集合は想定通り振る舞うことが保証されます。 tr/// は これらの範囲と同様に振る舞います。 In patterns, any ranges specified with end points using the パターンにおいて、\N{...} 記法を使ったエンドポイントで指定した 範囲は文字集合間で移植性がありますが、Perl 5.22 にはバグがより、これは tr/// には 当てはまりませんでした; v5.24 で修正されました。
Do not assume anything about the ordering of the characters. The lowercase letters may come before or after the uppercase letters; the lowercase and uppercase may be interlaced so that both "a" and "A" come before "b"; the accented and other international characters may be interlaced so that ä comes before "b". Unicode::Collate can be used to sort this all out.
文字の順序について何も仮定しないでください。 小文字は大文字の前かもしれませんし後かもしれません; 小文字と大文字が交互に 来るために、"a" と "A" の両方が "b" の前かもしれません; アクセント文字や その他の国際文字は交互に来るかも知れないので ä は "b" の 前かもしれません。 Unicode::Collate はこれらのソートに使えます。
国際化¶
If you may assume POSIX (a rather large assumption), you may read more about the POSIX locale system from perllocale. The locale system at least attempts to make things a little bit more portable, or at least more convenient and native-friendly for non-English users. The system affects character sets and encoding, and date and time formatting--amongst other things.
POSIX (比較的大きい仮定) を仮定するなら、perllocale から POSIX ロケールシステムについて多くを読めます。 ロケールシステムは少なくとも物事をもう少し移植性のある形にしようとする、 あるいは少なくとも非英語ユーザにとってより便利で母国語に親しくするものです。 このシステムは文字集合とエンコーディング、日付と時刻の形式 -- 他のものに 混じって -- に影響を与えます。
If you really want to be international, you should consider Unicode. See perluniintro and perlunicode for more information.
もし本当に国際化したいなら、Unicode を考慮するべきです。 さらなる情報については perluniintro と perlunicode を 参照してください。
By default Perl assumes your source code is written in an 8-bit ASCII superset. To embed Unicode characters in your strings and regexes, you can use the \x{HH} or (more portably) \N{U+HH} notations. You can also use the utf8 pragma and write your code in UTF-8, which lets you use Unicode characters directly (not just in quoted constructs but also in identifiers).
デフォルトでは Perl はソースコードが 8-bit ASCII 上位集合で書かれていると 仮定します。 文字列や正規表現に Unicode 文字を埋め込むには、 \x{HH} や (より移植性のある) \N{U+HH} 記法 を使えます。 また、utf8 プラグマを使ってコードを UTF-8 で書き、 Unicode 文字を直接 (単にクォートされた構造だけでなく識別子にも) 使うことも できます。
システムリソース¶
If your code is destined for systems with severely constrained (or missing!) virtual memory systems then you want to be especially mindful of avoiding wasteful constructs such as:
あなたのコードが仮想メモリについて厳しく制限された(あるいは存在しない!) システムで動作することになっているなら、特に 以下のような無駄な構造を 避けたいです:
my @lines = <$very_large_file>; # bad
while (<$fh>) {$file .= $_} # sometimes bad
my $file = join('', <$fh>); # betterThe last two constructs may appear unintuitive to most people. The first repeatedly grows a string, whereas the second allocates a large chunk of memory in one go. On some systems, the second is more efficient than the first.
最後の二つの構造はほとんどの人々にとって直観的ではないかもしれません。 一番目は徐々に文字列が大きくなり、二番目は一度に大きなメモリの塊を 割り当てます。 システムによっては、二番目の方が一番目よりも効率的です。
セキュリティ¶
Most multi-user platforms provide basic levels of security, usually implemented at the filesystem level. Some, however, unfortunately do not. Thus the notion of user id, or "home" directory, or even the state of being logged-in, may be unrecognizable on many platforms. If you write programs that are security-conscious, it is usually best to know what type of system you will be running under so that you can write code explicitly for that platform (or class of platforms).
ほとんどのマルチユーザプラットフォームでは(普通はファイルシステムで 実装された)基本的なレベルのセキュリティを提供しています。 しかし、一部は残念ながらそうではありません。 従ってユーザー ID、"home" ディレクトリ、あるいはログインしているかどうか という概念すら多くのプラットフォームでは認識できないかもしれません。 セキュリティを意識したプログラムを書くなら、どの種類のシステムで 実行されるかを知るのが普通は最良です; これによって明示的にその プラットフォーム(またはプラットフォームの種類)のためのコードを書けます。
Don't assume the Unix filesystem access semantics: the operating system or the filesystem may be using some ACL systems, which are richer languages than the usual rwx. Even if the rwx exist, their semantics might be different.
Unix のファイルシステムアクセス意味論を仮定しないでください: オペレーティングシステムやファイルシステムは通常の rwx よりも豊富な 機能を持つ ACL システムを使っているかもしれません。 rwx が存在したとしても、意味は違うかもしれません。
(From the security viewpoint, testing for permissions before attempting to do something is silly anyway: if one tries this, there is potential for race conditions. Someone or something might change the permissions between the permissions check and the actual operation. Just try the operation.)
(セキュリティの面からは、何かをしようとする前に権限をテストするのは そもそもばかげています: そうしようとすると、潜在的な競合条件があります。 権限チェックと実際の操作の間に誰かまたは何かが権限を変えるかもしれません。 単に操作を試してください。)
Don't assume the Unix user and group semantics: especially, don't expect $< and $> (or $( and $)) to work for switching identities (or memberships).
Unix のユーザーとグループの意味論を仮定しないでください: 特に、ユーザー (あるいはグループ)を切り替えるのに $< と $> (または $( と $)) が動作すると 想定しないでください。
Don't assume set-uid and set-gid semantics. (And even if you do, think twice: set-uid and set-gid are a known can of security worms.)
set-uid と set-gid の動作を仮定しないでください。 (そしてそうしたとしても、二度考えてください: set-uid と set-gid はセキュリティの虫の缶詰として知られています。)
スタイル¶
For those times when it is necessary to have platform-specific code, consider keeping the platform-specific code in one place, making porting to other platforms easier. Use the Config module and the special variable $^O to differentiate platforms, as described in "PLATFORMS".
プラットフォーム固有のコードを書く必要がある時には、プラットフォーム固有の コードを 1 箇所に集めて、他のプラットフォームへの移植をより容易にすることを 考慮してください。 "PLATFORMS" で記述されているように、プラットフォームを識別するために Config モジュールと特殊変数 $^O を 使ってください。
Beware of the "else syndrome":
「else 症候群」に注意してください:
if ($^O eq 'MSWin32') {
# code that assumes Windows
} else {
# code that assumes Linux
}The else branch should be used for the really ultimate fallback, not for code specific to some platform.
else 節は、あるプラットフォームに特有のコードのためではなく、 本当に究極のフォールバックに使うべきです。
Be careful in the tests you supply with your module or programs. Module code may be fully portable, but its tests might not be. This often happens when tests spawn off other processes or call external programs to aid in the testing, or when (as noted above) the tests assume certain things about the filesystem and paths. Be careful not to depend on a specific output style for errors, such as when checking $! after a failed system call. Using $! for anything else than displaying it as output is doubtful (though see the Errno module for testing reasonably portably for error value). Some platforms expect a certain output format, and Perl on those platforms may have been adjusted accordingly. Most specifically, don't anchor a regex when testing an error value.
モジュールやプログラムと共に提供するテストには注意してください。 モジュールのコードは完全に移植性があるかも知れませんが、 テストはそうではないかもしれません。 これは、テストの助けとするために他のプロセスを起動したり外部のプログラムを 呼び出したりしたり、テストが(上述したように)ファイルシステムやパスについて ある種の仮定をしたときにしばしば起こります。 システムコールに失敗したあとの $! のような、エラーの特定の 出力形式に依存しないように注意してください。 出力として表示する以外のことに $! を使うことは疑問が あります(しかしエラー値について十分な移植性のあるテストを刷るための Errno モジュールを参照してください)。 一部のプラットフォームはある種の出力形式を想定していて、それらの プラットフォームの Perl はそれに応じて調整します。 もっとも厳密に言えば、エラー値をテストするときに正規表現を 使わないでください。
CPAN Testers¶
Modules uploaded to CPAN are tested by a variety of volunteers on different platforms. These CPAN testers are notified by mail of each new upload, and reply to the list with PASS, FAIL, NA (not applicable to this platform), or UNKNOWN (unknown), along with any relevant notations.
CPAN にアップロードされたモジュールは色々なプラットフォームで 様々なボランティアによってテストされます。 これらの CPAN testers は新しくアップロードされることにメールによって 通知され、PASS, FAIL, NA (このプラットフォームでは不適切), UNKNOWN (不明) のいずれかを、関連する情報と共に返信します。
The purpose of the testing is twofold: one, to help developers fix any problems in their code that crop up because of lack of testing on other platforms; two, to provide users with information about whether a given module works on a given platform.
テストの目的は二つあります: 一つ目は、他のプラットフォームのテストが ないことによって突然現れるコードの問題を開発者が修正することを 助けるためです; 二つ目は、あるモジュールがあるプラットフォームで 動作するかどうかの情報をユーザーに提供することです。
Also see:
以下も参照してください:
-
Mailing list: [email protected]
メーリングリスト: [email protected]
-
Testing results: https://www.cpantesters.org/
テスト結果: https://www.cpantesters.org/
プラットフォーム¶
Perl is built with a $^O variable that indicates the operating system it was built on. This was implemented to help speed up code that would otherwise have to use Config and use the value of $Config{osname}. Of course, to get more detailed information about the system, looking into %Config is certainly recommended.
Perl は $^O 変数がビルドされたオペレーティング システムを示すような形でビルドされます。 これは、use Config して $Config{osname} の値を調べる必要がないようにすることで 高速化を助けています。 もちろんシステムからもっと詳細な情報を得るなら、 %Config を見ることが確実にお勧めです。
%Config cannot always be trusted, however, because it was built at compile time. If perl was built in one place, then transferred elsewhere, some values may be wrong. The values may even have been edited after the fact.
しかし、%Config はコンパイル時にビルドされるので、 常に信頼するというわけにはいきません。 perl がある場所でビルドされ、それから別の場所に移されると、いくつかの 値は間違ったものになるかもしれません。 値は後から変更することすらできます。
Unix¶
Perl works on a bewildering variety of Unix and Unix-like platforms (see e.g. most of the files in the hints/ directory in the source code kit). On most of these systems, the value of $^O (hence $Config{osname}, too) is determined either by lowercasing and stripping punctuation from the first field of the string returned by typing uname -a (or a similar command) at the shell prompt or by testing the file system for the presence of uniquely named files such as a kernel or header file. Here, for example, are a few of the more popular Unix flavors:
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
DYNIX/ptx dynixptx i386-dynixptx
FreeBSD freebsd freebsd-i386
Haiku haiku BePC-haiku
Linux linux arm-linux
Linux linux armv5tel-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
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-sunosBecause the value of $Config{archname} may depend on the hardware architecture, it can vary more than the value of $^O.
$Config{archname} の値はハードウェアアーキテクチャに 依存しているため、$^O の値よりも様々な値になります。
DOS とその派生¶
Perl has long been ported to Intel-style microcomputers running under systems like PC-DOS, MS-DOS, OS/2, and most Windows platforms you can bring yourself to mention (except for Windows CE, if you count that). Users familiar with COMMAND.COM or CMD.EXE style shells should be aware that each of these file specifications may have subtle differences:
Perl は昔から Intel 形式のマイクロコンピュータで動作する PC-DOS, MS-DOS, OS/2 のようなシステムと、あなたが指摘できるようなほとんど全ての Windows プラットフォーム(もし Windows CE を含めるなら、これは除きます)に 移植されてきました。 COMMAND.COM や CMD.EXE 形式のシェルになれているユーザーは、 以下のようなファイル指定に少しずつ違いがあることに気がつくはずです:
my $filespec0 = "c:/foo/bar/file.txt";
my $filespec1 = "c:\\foo\\bar\\file.txt";
my $filespec2 = 'c:\foo\bar\file.txt';
my $filespec3 = 'c:\\foo\\bar\\file.txt';System calls accept either / or \ as the path separator. However, many command-line utilities of DOS vintage treat / as the option prefix, so may get confused by filenames containing /. Aside from calling any external programs, / will work just fine, and probably better, as it is more consistent with popular usage, and avoids the problem of remembering what to backwhack and what not to.
システムコールはパス区切りとして / または \ のどちらかを受け付けます。 しかし、古い DOS のコマンドラインユーティリティは / をオプションの 接頭辞として扱うので、ファイル名に / が含まれていると混乱するかも しれません。 外部プログラムを呼び出すことを除いて、/ はとてもうまく動作し、おそらく よりよいです; なぜなら一般的な使用法でより一貫性があって、何が バックスラッシュで何が層でないかを覚えるという問題を避けられます。
The DOS FAT filesystem can accommodate only "8.3" style filenames. Under the "case-insensitive, but case-preserving" HPFS (OS/2) and NTFS (NT) filesystems you may have to be careful about case returned with functions like readdir or used with functions like open or opendir.
DOS FAT ファイルシステムは "8.3" 形式のファイル名にのみ対応しています。 「大文字小文字を無視するが、保存する」HPFS (OS/2) と NTFS (NT) ファイルシステムでは readdir のような 関数から返されたり、 open や opendir のような関数で使う 大文字小文字に注意する必要があるでしょう。
DOS also treats several filenames as special, such as AUX, PRN, NUL, CON, COM1, LPT1, LPT2, etc. Unfortunately, sometimes these filenames won't even work if you include an explicit directory prefix. It is best to avoid such filenames, if you want your code to be portable to DOS and its derivatives. It's hard to know what these all are, unfortunately.
DOS はまた、 AUX, PRN, NUL, CON, COM1, LPT1, LPT2 のようないくつかの ファイル名を特別に扱います。 残念ながら、ときどきこれらのファイル名は明示的なディレクトリ接頭辞に 含んでいても動作しません。 コードに DOS とその派生で移植性があるようにするには、これらのファイル名を 避けるのが最良です。 残念ながら、これら全てを知るのは難しいです。
Users of these operating systems may also wish to make use of scripts such as pl2bat.bat to put wrappers around your scripts.
これらのオペレーティングシステムのユーザーは、スクリプトのラッパーとして pl2bat.bat のようなスクリプトを使ってください。
Newline (\n) is translated as \015\012 by the I/O system when reading from and writing to files (see "Newlines"). binmode($filehandle) will keep \n translated as \012 for that filehandle. binmode should always be used for code that deals with binary data. That's assuming you realize in advance that your data is in binary. General-purpose programs should often assume nothing about their data.
ファイルから読み書きするとき、改行 (\n) は I/O システムによって \015\012 に変換されます("Newlines" を参照してください)。 binmode($filehandle) は、このファイルハンドルに対して \n を \012 として変換されます。 バイナリデータを扱うコードでは常に binmode を使うべきです。 これは、予めデータがバイナリであることが分かっていることを仮定しています。 汎用プログラムはデータについて何も仮定しないべきです。
The $^O variable and the $Config{archname} values for various DOSish perls are as follows:
様々な 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 Vista MSWin32 MSWin32-x86 2 6 00
Windows 7 MSWin32 MSWin32-x86 2 6 01
Windows 7 MSWin32 MSWin32-x64 2 6 01
Windows 2008 MSWin32 MSWin32-x86 2 6 01
Windows 2008 MSWin32 MSWin32-x64 2 6 01
Windows CE MSWin32 ? 3
Cygwin cygwin cygwinThe various MSWin32 Perl's can distinguish the OS they are running on via the value of the fifth element of the list returned from Win32::GetOSVersion(). For example:
様々な 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";
}There are also Win32::IsWinNT()|Win32/Win32::IsWinNT(), Win32::IsWin95()|Win32/Win32::IsWin95(), and Win32::GetOSName(); try perldoc Win32. The very portable POSIX::uname() will work too:
また Win32::IsWinNT()|Win32/Win32::IsWinNT(), Win32::IsWin95()|Win32/Win32::IsWin95(), Win32::GetOSName() もあります; perldoc Win32 を試してみてください。 とても移植性のある POSIX::uname() も動作します:
c:\> perl -MPOSIX -we "print join '|', uname"
Windows NT|moonru|5.0|Build 2195 (Service Pack 2)|x86Errors set by Winsock functions are now put directly into $^E, and the relevant WSAE* error codes are now exported from the Errno and POSIX modules for testing this against.
Winsock 関数によって設定されたエラーは直接 $^E に設定されるようになり、 関連する WSAE* エラーコードはこれをテストするために Errno および POSIX モジュールからエクスポートされるようになりました。
The previous behavior of putting the errors (converted to POSIX-style E* error codes since Perl 5.20.0) into $! was buggy due to the non-equivalence of like-named Winsock and POSIX error constants, a relationship between which has unfortunately been established in one way or another since Perl 5.8.0.
(Perl 5.20.0 からの、E* エラーコードを POSIX 形式への変換して) エラーを$! に設定するという以前の振る舞いは、 E* error codes since Perl 5.20.0) into was buggy due to 似たような名前の Winsock と POSIC エラー定数の非等価性、 Perl 5.8.0 から不幸にも一方向に確立された関係によって、 バグを含んでいます。
The new behavior provides a much more robust solution for checking Winsock errors in portable software without accidentally matching POSIX tests that were intended for other OSes and may have different meanings for Winsock.
新しい振る舞いは、他の OS を想定した POSIX テストと Winsock では異なる意味を 持つかもしれないものが偶然一致するということなしに、 移植性のあるソフトウェアで Winsock のエラーをチェックするための 遥かに堅牢な解法を提供します。
The old behavior is currently retained, warts and all, for backwards compatibility, but users are encouraged to change any code that tests $! against E* constants for Winsock errors to instead test $^E against WSAE* constants. After a suitable deprecation period, which started with Perl 5.24, the old behavior may be removed, leaving $! unchanged after Winsock function calls, to avoid any possible confusion over which error variable to check.
現在のところ後方互換性のために古い振る舞いも欠点も含めてありのまま 残っていますが、ユーザーは Winsock のために $! を E* 定数と テストしている全てのコードを $^E を WSAE* 定数とテストするように 変更することが推奨されます。 Perl 5.24 から始まった適切な廃止予定期間の後、古い振る舞いは削除され、 チェックするエラー変数に関するあらゆる混乱を避けるために、 Winsock 関数呼び出しでは $! は変更されなくなります。
Also see:
以下も参照してください:
-
The EMX environment for DOS, OS/2, etc. [email protected], ftp://hobbes.nmsu.edu/pub/os2/dev/emx/ Also perlos2.
DOS, OS/2 のための EMX 環境 [email protected], ftp://hobbes.nmsu.edu/pub/os2/dev/emx/ および perlos2。
-
Build instructions for Win32 in perlwin32, or under the Cygnus environment in perlcygwin.
perlwin32 にある Win32 のためのビルド手順および perlcygwin にある Cygnus 環境。
-
The
Win32::*modules in Win32.Win32 の
Win32::*モジュール。 -
The ActiveState Pages, https://www.activestate.com/
ActiveState のページ, https://www.activestate.com/
-
The Cygwin environment for Win32; README.cygwin (installed as perlcygwin), https://www.cygwin.com/
Win32 のための Cygwin 環境; README.cygwin (perlcygwin として インストールされます), https://www.cygwin.com/
-
Build instructions for OS/2, perlos2
OS/2 のためのビルド手順である perlos2
VMS¶
Perl on VMS is discussed in perlvms in the Perl distribution.
VMS での Perl は Perl 配布の perlvms で議論されています。
The official name of VMS as of this writing is OpenVMS.
これを書いている時点での VMS の正式名称は OpenVMS です。
Interacting with Perl from the Digital Command Language (DCL) shell often requires a different set of quotation marks than Unix shells do. For example:
Perl と Digital Command Language (DCL) シェルとの相互作用はしばしば Unix シェルが行うのと異なるクォートの種類が必要になります。 例えば:
$ perl -e "print ""Hello, world.\n"""
Hello, world.There are several ways to wrap your Perl scripts in DCL .COM files, if you are so inclined. For example:
もしそうしたいなら、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__
$ endifDo take care with $ ASSIGN/nolog/user SYS$COMMAND: SYS$INPUT if your Perl-in-DCL script expects to do things like $read = <STDIN>;.
Perl-in-DCL スクリプトで $read = <STDIN>; のようなことを することを想定しているなら、$ ASSIGN/nolog/user SYS$COMMAND: SYS$INPUT に 注意してください。
The VMS operating system has two filesystems, designated by their on-disk structure (ODS) level: ODS-2 and its successor ODS-5. The initial port of Perl to VMS pre-dates ODS-5, but all current testing and development assumes ODS-5 and its capabilities, including case preservation, extended characters in filespecs, and names up to 8192 bytes long.
VMS オペレーティングシステムには、on-disk structure (ODS) レベルによって 指定された二つのファイルシステムがあります: ODS-2 とその後継の ODS-5 です。 Perl から VMS への初期移植は ODS-5 以前の時代でしたが、 現在の全てのテストと開発は、大文字小文字の保存、filespecs の拡張文字、 8192 バイトまでの名前のような、ODS-5 とその性能を仮定しています。
Perl on VMS can accept either VMS- or Unix-style file specifications as in either of the following:
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.combut not a mixture of both as in:
しかし以下のように両方を混ぜることはできません:
$ perl -ne "print if /perl_setup/i" sys$login:/login.com
Can't open sys$login:/login.com: file specification syntax errorIn general, the easiest path to portability is always to specify filenames in Unix format unless they will need to be processed by native commands or utilities. Because of this latter consideration, the File::Spec module by default returns native format specifications regardless of input format. This default may be reversed so that filenames are always reported in Unix format by specifying the DECC$FILENAME_UNIX_REPORT feature logical in the environment.
一般的に、最も簡単な移植性のあるパスは、ネイティブなコマンドや ユーティリティで処理する必要がない限り、 常に Unix 型式でファイル名を指定することです。 後者を考慮して、 File::Spec モジュールはデフォルトでは入力形式に関わらず ネイティブなフォーマット仕様を返します。 このデフォルトは、環境で DECC$FILENAME_UNIX_REPORT 機能論理を 指定することで、常に Unix 型式でファイル名を報告するように変更できます。
The file type, or extension, is always present in a VMS-format file specification even if it's zero-length. This means that, by default, readdir will return a trailing dot on a file with no extension, so where you would see "a" on Unix you'll see "a." on VMS. However, the trailing dot may be suppressed by enabling the DECC$READDIR_DROPDOTNOTYPE feature in the environment (see the CRTL documentation on feature logical names).
ファイル型(拡張子)は、(例え長さ 0 でも)VMS フォーマットファイル仕様では 常に存在します。 これは、デフォルトでは、 readdir は拡張子のないファイルに対して末尾の ピリオドを返し、Unix で "a" に見えるものが VMS では "a." に 見えることを意味します。 しかし、環境で DECC$READDIR_DROPDOTNOTYPE 機能を有効にすることで、 末尾のドットを省略できます (機能論理名については CRTL 文書を参照してください)。
What \n represents depends on the type of file opened. It usually represents \012 but it could also be \015, \012, \015\012, \000, \040, or nothing depending on the file organization and record format. The VMS::Stdio module provides access to the special fopen() requirements of files with unusual attributes on VMS.
\n が表現しているものはファイルを開く種類に依存します。 普通は \012 を表現しますが、ファイルの構成や記録形式に依存して \015, \012, \015\012, \000, \040 あるいは 何もなしかもしれません。 VMS::Stdio モジュールは VMS での普通でない属性付きの ファイルの特殊な fopen() へのアクセスを提供します。
The value of $^O on OpenVMS is "VMS". To determine the architecture that you are running on refer to $Config{archname}.
OpenVMS での $^O の値は "VMS" です。 実行しているアーキテクチャを決定するには、 $Config{archname} を参照します。
On VMS, perl determines the UTC offset from the SYS$TIMEZONE_DIFFERENTIAL logical name. Although the VMS epoch began at 17-NOV-1858 00:00:00.00, calls to localtime are adjusted to count offsets from 01-JAN-1970 00:00:00.00, just like Unix.
VMS では、perl は UTC オフセットを SYS$TIMEZONE_DIFFERENTIAL 論理名から 決定します。 VMS の紀元は 17-NOV-1858 00:00:00.00 に始まりますが、 localtime の呼び出しは Unix と同様 01-JAN-1970 00:00:00.00 からのオフセットに調整されます。
Also see:
以下も参照してください:
-
README.vms (installed as README_vms), perlvms
README.vms (README_vms としてインストールされます), perlvms
-
vmsperl list, [email protected]
vmsperl メーリングリスト: [email protected]
-
vmsperl on the web, http://www.sidhe.org/vmsperl/index.html
web 上の vmsperl: http://www.sidhe.org/vmsperl/index.html
-
VMS Software Inc. web site, http://www.vmssoftware.com
VMS Software Inc. web サイト, http://www.vmssoftware.com
VOS¶
Perl on VOS (also known as OpenVOS) is discussed in README.vos in the Perl distribution (installed as perlvos). Perl on VOS can accept either VOS- or Unix-style file specifications as in either of the following:
VOS (OpenVOS としても知られます) での 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/noticesor even a mixture of both as in:
あるいは両方を混ぜて:
$ perl -ne "print if /perl_setup/i" >system/noticesEven though VOS allows the slash character to appear in object names, because the VOS port of Perl interprets it as a pathname delimiting character, VOS files, directories, or links whose names contain a slash character cannot be processed. Such files must be renamed before they can be processed by Perl.
VOS はオブジェクト名としてスラッシュ文字が現れることを許していますが、 VOS 版の Perl インタプリタはこれをパス名を分割する文字として解釈するので、 名前にスラッシュ文字を含む VOS ファイル、ディレクトリ、リンクは 処理できません。 このようなファイルは Perl によって処理される前に リネームされなければなりません。
Older releases of VOS (prior to OpenVOS Release 17.0) limit file names to 32 or fewer characters, prohibit file names from starting with a - character, and prohibit file names from containing (space) or any character from the set !#%&'()*;<=>?.
古いリリースのVOS(OpenVOS リリース 17.0 以前) ではファイル名を 32 文字 以下に制限していたり、ファイル名を - 文字で始められなかったり、 スペースまたは集合 !#%&'()*;<=>? の文字を含むことができないという制限があります。
Newer releases of VOS (OpenVOS Release 17.0 or later) support a feature known as extended names. On these releases, file names can contain up to 255 characters, are prohibited from starting with a - character, and the set of prohibited characters is reduced to #%*<>?. There are restrictions involving spaces and apostrophes: these characters must not begin or end a name, nor can they immediately precede or follow a period. Additionally, a space must not immediately precede another space or hyphen. Specifically, the following character combinations are prohibited: space-space, space-hyphen, period-space, space-period, period-apostrophe, apostrophe-period, leading or trailing space, and leading or trailing apostrophe. Although an extended file name is limited to 255 characters, a path name is still limited to 256 characters.
より新しい VOS (OpenVOS リリース 17.0 以降) は拡張名として知られる機能に 対応しています。 これらのリリースでは、ファイル名は 255 文字までで、- 文字で始めることは 禁止され、禁止される文字は #%*<>? に減少しました。 スペースとアポストロフィに関する制限があります: これらの文字は名前の 先頭や末尾、ピリオドの直前や直後には使えません。 更に、スペースはその他のスペースやハイフンの前には使えません。 特に、以下のような文字の組み合わせは禁止されます: スペース-スペース、 スペース-ハイフン、ピリオド-スペース、スペース-ピリオド、 ピリオド-アポストロフィ、アポストロフィ-ピリオド、先頭または末尾のスペース、 先頭または末尾のアポストロフィ。 拡張ファイル名は 255 文字に制限されていますが、パス名は 256 文字に 制限されたままです。
The value of $^O on VOS is "vos". To determine the architecture that you are running on refer to $Config{archname}.
VOS での $^O の値は "vos" です。 実行しているアーキテクチャを決定するには、 $Config{archname} を参照します。
Also see:
以下も参照してください:
-
README.vos (installed as perlvos)
README.vos (perlvos としてインストールされます)
-
The VOS mailing list.
VOS メーリングリスト。
There is no specific mailing list for Perl on VOS. You can contact the Stratus Technologies Customer Assistance Center (CAC) for your region, or you can use the contact information located in the distribution files on the Stratus Anonymous FTP site.
VOS での Perl 専用のメーリングリストはありません。 あなたの地域の Stratus Technologies Customer Assistance Center (CAC) に 連絡を取るか、Stratus Anonymous FTP サイトの配布ファイルにある連絡情報を 使ってください。
-
Stratus Technologies on the web at http://www.stratus.com
http://ftp.stratus.com/pub/vos/posix/posix.html にある Stratus Technologies の web サイト
-
VOS Open-Source Software on the web at http://ftp.stratus.com/pub/vos/vos.html
http://ftp.stratus.com/pub/vos/vos.html にある VOS Open-Source Software の web サイト
EBCDIC プラットフォーム¶
v5.22 core Perl runs on z/OS (formerly OS/390). Theoretically it could run on the successors of OS/400 on AS/400 minicomputers as well as VM/ESA, and BS2000 for S/390 Mainframes. Such computers use EBCDIC character sets internally (usually Character Code Set ID 0037 for OS/400 and either 1047 or POSIX-BC for S/390 systems).
v5.22 コア Perl は z/OS (以前は OS/390) で実行されます。 理論的には、AS/400 ミニコンピュータでの OS/400 の後継、 S/390 メインフレームでの VM/ESA, BS2000 のようなプラットフォームに 移植されています。 このようなコンピュータは内部で EBCDIC 文字集合 (通常は OS/400 では Character Code Set ID 0037、S/390 では 1047 または POSIX-BC の どちらか) を内部で使います。
The rest of this section may need updating, but we don't know what it should say. Please submit comments to https://github.com/Perl/perl5/issues.
この章の残りの部分は更新する必要がありますが、私たちはどうすれば良いか 分かっていません。 https://github.com/Perl/perl5/issues に コメントを登録してください。
On the mainframe Perl currently works under the "Unix system services for OS/390" (formerly known as OpenEdition), VM/ESA OpenEdition, or the BS200 POSIX-BC system (BS2000 is supported in Perl 5.6 and greater). See perlos390 for details. Note that for OS/400 there is also a port of Perl 5.8.1/5.10.0 or later to the PASE which is ASCII-based (as opposed to ILE which is EBCDIC-based), see perlos400.
メインフレーム Perl は現在のところ "Unix system services for OS/390" (以前は OpenEdition として知られていたもの), VM/ESA OpenEdition, BS200 POSIX-BC システムで動作します (BS2000 は Perl 5.6 以降で対応します)。 詳しくは perlos390 を参照してください。 OS/400 には (EBCDIC ベースの ILE ではなく) ASCII ベースの PASE への Perl 5.8.1/5.10.0 以降の移植もあることに注意してください; perlos400 を 参照してください。
As of R2.5 of USS for OS/390 and Version 2.3 of VM/ESA these Unix sub-systems do not support the #! shebang trick for script invocation. Hence, on OS/390 and VM/ESA Perl scripts can be executed with a header similar to the following simple script:
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 will support the #! shebang trick in release 2.8 and beyond. Calls to system and backticks can use POSIX shell syntax on all S/390 systems.
OS/390 はリリース 2.8 以降、#! トリックに対応しています。 system と逆クォートの呼び出しは全ての S/390 システムで POSIX シェル文法を使います。
On the AS/400, if PERL5 is in your library list, you may need to wrap your Perl scripts in a CL procedure to invoke them like so:
AS/400 では、ライブラリリストに PERL5 があれば、以下のようにして CL プロシージャーで Perl スクリプトをラップする必要があります:
BEGIN
CALL PGM(PERL5/PERL) PARM('/QOpenSys/hello.pl')
ENDPGMThis will invoke the Perl script hello.pl in the root of the QOpenSys file system. On the AS/400 calls to system or backticks must use CL syntax.
これは QOpenSys ファイルシステムのルートにある Perl スクリプト hello.pl を起動します。 AS/400 では system や逆クォートの呼び出しは CL 文法を使わなければなりません。
On these platforms, bear in mind that the EBCDIC character set may have an effect on what happens with some Perl functions (such as chr, pack, print, printf, ord, sort, sprintf, unpack), as well as bit-fiddling with ASCII constants using operators like ^, & and |, not to mention dealing with socket interfaces to ASCII computers (see "Newlines").
これらのプラットフォームでは、( chr, pack, print, printf, ord, sort, sprintf, unpack のような) 一部の Perl の関数および、 ^, &, | のような演算子を使った ASCII 定数のビット操作での効果が EBCDIC 文字では異なることがあることに 注意してください; ASCII コンピュータへのソケットインターフェースを 扱うことを言及しません ("Newlines" 参照)。
Fortunately, most web servers for the mainframe will correctly translate the \n in the following statement to its ASCII equivalent (\r is the same under both Unix and z/OS):
幸いにも、メインフレームのほとんどの web サーバは以下の文の \n を ASCII の等価物に正しく変換します (\r は Unix と z/OS で同じです):
print "Content-type: text/html\r\n\r\n";The values of $^O on some of these platforms include:
これらのプラットフォームの $^O の値は以下のようなものです:
uname $^O $Config{archname}
--------------------------------------------
OS/390 os390 os390
OS400 os400 os400
POSIX-BC posix-bc BS2000-posix-bcSome simple tricks for determining if you are running on an EBCDIC platform could include any of the following (perhaps all):
EBCDIC プラットフォームで実行されているかどうかを決定するための 単純なトリックとしては、以下のどれか(おそらく全て)があります:
if ("\t" eq "\005") { 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"; }One thing you may not want to rely on is the EBCDIC encoding of punctuation characters since these may differ from code page to code page (and once your module or script is rumoured to work with EBCDIC, folks will want it to work with all EBCDIC character sets).
依存したいと思わないだろうことの一つは、句読点文字の EBCDIC エンコードでしょう; これらはコードページによって異なるからです (そして一旦あなたのモジュールやスクリプトが EBCDIC で動作すると噂されると、 人々は全ての EBCDIC 文字集合で動作することを求めます)。
Also see:
以下も参照してください:
-
The [email protected] list is for discussion of porting issues as well as general usage issues for all EBCDIC Perls. Send a message body of "subscribe perl-mvs" to [email protected].
[email protected] メーリングリストは移植の問題および全ての EBCDIC Perl に 関する一般的な使用法について議論するための物です。 メッセージ本体に "subscribe perl-mvs" と書いて [email protected] に 送ってください。
-
AS/400 Perl information at http://as400.rochester.ibm.com/ as well as on CPAN in the ports/ directory.
http://as400.rochester.ibm.com/ の AS/400 Perl 情報および CPAN の ports/ ディレクトリ。
Acorn RISC OS¶
Because Acorns use ASCII with newlines (\n) in text files as \012 like Unix, and because Unix filename emulation is turned on by default, most simple scripts will probably work "out of the box". The native filesystem is modular, and individual filesystems are free to be case-sensitive or insensitive, and are usually case-preserving. Some native filesystems have name length limits, which file and directory names are silently truncated to fit. Scripts should be aware that the standard filesystem currently has a name length limit of 10 characters, with up to 77 items in a directory, but other filesystems may not impose such limitations.
Acorns は Unix と同様 ASCII を使い、テキストファイルの改行 (\n) に \012 を使うのと、Unix ファイル名エミュレーションがデフォルトで 有効なので、ほとんどの単純なスクリプトはおそらく「そのまま」で動作します。 ネイティブなファイルシステムはモジュラー形式で、個々のファイルシステムは 大文字小文字を区別するかしないかは関係なく、普通は大文字小文字を保存します。 ネイティブなファイルシステムの一部は名前の長さに制限があり、 ファイル名とディレクトリ名は収まるように暗黙に切り詰められます。 スクリプトは、標準ファイルシステムは名前の長さが 10 に制限され、一つの ディレクトリに77 アイテムまでに制限されることに注意するべきです; しかし他のファイルシステムはこのような制限はないかもしれません。
Native filenames are of the form
ネイティブなファイル名は以下の形式です:
Filesystem#Special_Field::DiskName.$.Directory.Directory.Filewhere
それぞれは以下の通りです:
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]+|The default filename translation is roughly tr|/.|./|, swapping dots and slashes.
デフォルトファイル名変換はだいたい tr|/.|./| です; ドットとスラッシュを 入れ替えます。
Note that "ADFS::HardDisk.$.File" ne 'ADFS::HardDisk.$.File' and that the second stage of $ interpolation in regular expressions will fall foul of the $. variable if scripts are not careful.
"ADFS::HardDisk.$.File" ne 'ADFS::HardDisk.$.File' と、正規表現中の $ 展開の第 2 ステージは、スクリプトが注意深くなければ $. を落とすことに注意してください。
Logical paths specified by system variables containing comma-separated search lists are also allowed; hence System:Modules is a valid filename, and the filesystem will prefix Modules with each section of System$Path until a name is made that points to an object on disk. Writing to a new file System:Modules would be allowed only if System$Path contains a single item list. The filesystem will also expand system variables in filenames if enclosed in angle brackets, so <System$Dir>.Modules would look for the file $ENV{'System$Dir'} . 'Modules'. The obvious implication of this is that fully qualified filenames can start with <> and the three-argument form of open should always be used.
カンマ区切りの検索リストを含むシステム変数で指定された論理パスも使えます; 従って System:Modules は妥当なファイル名で、 ファイルシステムは、名前がディスク上のオブジェクトを指すようになるまで System$Path のそれぞれの部分に Modules を前置します。 System$Path に単一のアイテムリストが含まれている場合にのみ、 新しいファイル System:Modules に書き込めます。 ファイルシステムはファイル名にシステム変数が角かっこで囲まれていると 展開するので、 <System$Dir>.Modules は $ENV{'System$Dir'} . 'Modules' というファイルを探します。 ここから明らかに推測されることは、 完全修飾ファイル名は <> で始まることがあり、 3 引数形式の open が常に 使われるべきということです。
Because . was in use as a directory separator and filenames could not be assumed to be unique after 10 characters, Acorn implemented the C compiler to strip the trailing .c .h .s and .o suffix from filenames specified in source code and store the respective files in subdirectories named after the suffix. Hence files are translated:
. がディレクトリセパレータとして使われていて、ファイル名の 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)The Unix emulation library's translation of filenames to native assumes that this sort of translation is required, and it allows a user-defined list of known suffixes that it will transpose in this fashion. This may seem transparent, but consider that with these rules foo/bar/baz.h and foo/bar/h/baz both map to foo.bar.h.baz, and that readdir and glob cannot and do not attempt to emulate the reverse mapping. Other .'s in filenames are translated to /.
Unix エミュレーションライブラリのファイル名のネイティブへの変換は この種の変換が必要であることを仮定していて、この方法で入れ替える既知の 拡張子のリストをユーザー定義できるようになっています。 これは透過的に思えますが、これらの規則では foo/bar/baz.h と foo/bar/h/baz の両方が foo.bar.h.baz にマッピングされ、 readdir と glob は 逆マッピングのエミュレートを試みることができないことを考慮してください。 ファイル名中のその他の . は / に変換されます。
As implied above, the environment accessed through %ENV is global, and the convention is that program specific environment variables are of the form Program$Name. Each filesystem maintains a current directory, and the current filesystem's current directory is the global current directory. Consequently, sociable programs don't change the current directory but rely on full pathnames, and programs (and Makefiles) cannot assume that they can spawn a child process which can change the current directory without affecting its parent (and everyone else for that matter).
すでに暗示したように、%ENV を通してアクセスする環境はグローバルで、 プログラム固有環境変数は Program$Name の形に変換されます。 それぞれのファイルシステムはカレントディレクトリを管理し、現在の ファイルシステムのカレントディレクトリは グローバルな カレントディレクトリです。 従って、社交的なプログラムはカレントディレクトリを変更せずに フルパス名に頼り、プログラム(および Makefile) は親 (およびこの意味では その他あらゆるもの)に影響を与えずにカレントディレクトリを変更できる 子プロセスを作成できると仮定できません。
Because native operating system filehandles are global and are currently allocated down from 255, with 0 being a reserved value, the Unix emulation library emulates Unix filehandles. Consequently, you can't rely on passing STDIN, STDOUT, or STDERR to your children.
ネイティブオペレーティングシステムファイルハンドルはグローバルで 現在のところ 255 から下向きに割り当てられ、0 は予約された値なので、 Unix エミュレーションライブラリは Unix ファイルハンドルをエミュレートします。 従って、STDIN, STDOUT, STDERR を子プロセスに渡すことに 頼れません。
The desire of users to express filenames of the form <Foo$Dir>.Bar on the command line unquoted causes problems, too: `` command output capture has to perform a guessing game. It assumes that a string <[^<>]+\$[^<>]> is a reference to an environment variable, whereas anything else involving < or > is redirection, and generally manages to be 99% right. Of course, the problem remains that scripts cannot rely on any Unix tools being available, or that any tools found have Unix-like command line arguments.
コマンドラインでクォートなしに <Foo$Dir>.Bar 形式のファイル名を 記述するというユーザーの欲求も問題を引き起こします: `` コマンド出力捕捉は 推論ゲームをする必要があります。 <[^<>]+\$[^<>]> は環境変数の参照、それ以外の < や > が 関係する全てはリダイレクトと推測し、これは一般的に何とか 99% は正しいです。 もちろん、スクリプトはどの Unix ツールが利用可能であることや、見つけた ツールが Unix 風のコマンドライン引数を取ることには頼れないという問題は 残っています。
Extensions and XS are, in theory, buildable by anyone using free tools. In practice, many don't, as users of the Acorn platform are used to binary distributions. MakeMaker does run, but no available make currently copes with MakeMaker's makefiles; even if and when this should be fixed, the lack of a Unix-like shell will cause problems with makefile rules, especially lines of the form cd sdbm && make all, and anything using quoting.
エクステンションと XS は、理論的には、自由なツールを使って誰でも ビルドできます。 実際には、多くの人はできません; Acorn プラットフォームのユーザーは バイナリ配布を使っているからです。 MakeMaker は実行できますが、現在のところ MakeMaker の makefile を処理できる make はありません; たとえこれが修正されても、Unix 風シェルがないので makefile 規則で問題が起こります; 特に cd sdbm && make all 形式の行や、 クォートを使ったものです。
"RISC OS" is the proper name for the operating system, but the value in $^O is "riscos" (because we don't like shouting).
"RISC OS" はオペレーティングシステムの適切な名前ですが、 $^O の値は "riscos" です(大文字は好まないからです)。
その他の perl¶
Perl has been ported to many platforms that do not fit into any of the categories listed above. Some, such as AmigaOS, QNX, Plan 9, and VOS, have been well-integrated into the standard Perl source code kit. You may need to see the ports/ directory on CPAN for information, and possibly binaries, for the likes of: aos, Atari ST, lynxos, riscos, Novell Netware, Tandem Guardian, etc. (Yes, we know that some of these OSes may fall under the Unix category, but we are not a standards body.)
Perl は上述したカテゴリ一覧のどれにも当てはまらないような多くの プラットフォームに移植されています。 AmigaOS, QNX, Plan 9, VOS のような一部のものは標準 Perl ソースコードキットと よく統合されています。 Atari ST, lynxos, riscos, Novell Netware, Tandem Guardian など の ようなものについての情報とおそらくバイナリを得るために CPAN の ports/ ディレクトリを見る必要があるかもしれません: (はい、これらの OS の一部は Unix カテゴリに入ることを知っていますが、 私たちは標準の組織ではありません。)
Some approximate operating system names and their $^O values in the "OTHER" category include:
"OTHER" カテゴリにあるいくつかの近似オペレーティングシステム名と その $^O の値は以下のようなものです:
OS $^O $Config{archname}
------------------------------------------
Amiga DOS amigaos m68k-amigosSee also:
以下も参照してください:
-
Amiga, README.amiga (installed as perlamiga).
Amiga, README.amiga (perlamiga としてインストールされます)
Plan 9, README.plan9
関数実装¶
Listed below are functions that are either completely unimplemented or else have been implemented differently on various platforms. Preceding each description will be, in parentheses, a list of platforms that the description applies to.
以下の一覧は、プラットフォームによって全く実装されていないか、 さもなければ異なった形で実装されている関数です。 それぞれの記述にあるかっこは、記述が適用されるプラットフォームの一覧です。
The list may well be incomplete, or even wrong in some places. When in doubt, consult the platform-specific README files in the Perl source distribution, and any other documentation resources accompanying a given port.
一覧は不完全であったり、一部で間違っている可能性があります。 疑わしいときは、Perl ソース配布のプラットフォーム固有の README ファイルや、 プラットフォームに関連するその他の文書リソースをチェックしてください。
Be aware, moreover, that even among Unix-ish systems there are variations.
さらに、Unix 風システムにもバリエーションがあることに注意してください。
For many functions, you can also query %Config, exported by default from the Config module. For example, to check whether the platform has the lstat call, check $Config{d_lstat}. See Config for a full description of available variables.
多くの関数に関して、Config モジュールから デフォルトでエクスポートされる %Config に問い合わせることもできます。 例えば、プラットフォームに lstat 呼び出しが あるかどうかを調べるには、 $Config{d_lstat} を調べてください。 利用可能な変数の完全な説明については Config を参照してください。
Perl 関数のアルファベット順リスト¶
- -X
-
(Win32)
-wonly inspects the read-only file attribute (FILE_ATTRIBUTE_READONLY), which determines whether the directory can be deleted, not whether it can be written to. Directories always have read and write access unless denied by discretionary access control lists (DACLs).(Win32)
-wは読み込み専用ファイル属性 (FILE_ATTRIBUTE_READONLY) のみを調べます; これはディレクトリに書き込めるかどうかではなくディレクトリが 削除できるかどうかを決定します。 ディレクトリは、随意アクセス制御リスト (DACL) で拒否されない限り、常に 読み書きアクセスできます。(VMS)
-r,-w,-x, and-otell whether the file is accessible, which may not reflect UIC-based file protections.(VMS)
-r,-w,-x,-oはファイルがアクセス可能かどうかを返し、 UIC ベースのファイル保護を反映しません。(RISC OS)
-sby name on an open file will return the space reserved on disk, rather than the current extent.-son an open filehandle returns the current size.(RISC OS) 開いているファイルへの名前での
-sは、現在のエクステントではなく、 ディスク上に予約されている空間を返します。 開いているファイルハンドルへの-sは現在のサイズを返します。(Win32, VMS, RISC OS)
-R,-W,-X,-Oare indistinguishable from-r,-w,-x,-o.(Win32, VMS, RISC OS)
-R,-W,-X,-Oは、-r,-w,-x,-oと 区別が付きません。(Win32, VMS, RISC OS)
-g,-k,-l,-u,-Aare not particularly meaningful.(Win32, VMS, RISC OS)
-g,-k,-l,-u,-Aは特に意味はありません。(Win32)
-lreturns true for both symlinks and directory junctions.(Win32)
-lは、シンボリックリンクとディレクトリジャンクションの両方で 真を返します。(VMS, RISC OS)
-pis not particularly meaningful.(VMS, RISC OS)
-pは特に意味はありません。(VMS)
-dis true if passed a device spec without an explicit directory.(VMS)
-dは、明示的なディレクトリなしに device spec を渡されると真になります。(Win32)
-x(or-X) determine if a file ends in one of the executable suffixes.-Sis meaningless.(Win32)
-x(または-X) はファイルが実行可能ファイルの拡張子のどれかで 終わっているかを判定します。-Sは無意味です。(RISC OS)
-x(or-X) determine if a file has an executable file type.(RISC OS)
-x(または-X) ファイルが実行可能ファイル型かどうかを 決定します。 - alarm
-
(Win32) Emulated using timers that must be explicitly polled whenever Perl wants to dispatch "safe signals" and therefore cannot interrupt blocking system calls.
(Win32) Perl が「安全なシグナル」を発行したいタイミングで明示的に ポーリングされなければならないタイマーを使ってエミュレートされ、 従ってシステムコールのブロックに割り込めません。
- atan2
-
(Tru64, HP-UX 10.20) Due to issues with various CPUs, math libraries, compilers, and standards, results for
atan2may vary depending on any combination of the above. Perl attempts to conform to the Open Group/IEEE standards for the results returned fromatan2, but cannot force the issue if the system Perl is run on does not allow it.(Tru64, HP-UX 10.20) 様々な CPU、数値演算ライブラリ、コンパイラ、標準の問題により、
atan2の 結果は上述の組み合わせに依存して様々に異なります。 Perl はatan2から返される結果を Open Group/IEEE 標準に 準拠させようとしますが、システムの Perl がそれを許さないところで 動作している場合は問題を強制させることはできません。The current version of the standards for
atan2is available at http://www.opengroup.org/onlinepubs/009695399/functions/atan2.html.atan2の現在のバージョンの標準は http://www.opengroup.org/onlinepubs/009695399/functions/atan2.html で 利用可能です。 - binmode
-
(RISC OS) Meaningless.
(RISC OS) 無意味です。
(VMS) Reopens file and restores pointer; if function fails, underlying filehandle may be closed, or pointer may be in a different position.
(VMS) ファイルの再オープンとポインタの復帰; 関数が失敗すると、基となる ファイルハンドルが閉じられたり、ポインタが異なった位置を示すことが あります。
(Win32) The value returned by
tellmay be affected after the call, and the filehandle may be flushed.(Win32)
tellから返された値はこの呼び出しの後に 影響を受けることがあり、ファイルハンドルがフラッシュされることがあります。 - chdir
-
(Win32) The current directory reported by the system may include any symbolic links specified to chdir().
(Win32) システムによって報告されるカレントディレクトリは chdir() で指定されたシンボリックリンクを含むことがあります。
- chmod
-
(Win32) Only good for changing "owner" read-write access; "group" and "other" bits are meaningless.
(Win32) 「所有者」読み書きアクセスの変更のみ動作します;「グループ」「その他」の ビットは無意味です。
(RISC OS) Only good for changing "owner" and "other" read-write access.
(RISC OS) 「所有者」と「その他」の読み書きアクセスの変更のみ動作します。
(VOS) Access permissions are mapped onto VOS access-control list changes.
(VOS) アクセス許可は VOS アクセス制御リスト変更に割り当てられます。
(Cygwin) The actual permissions set depend on the value of the
CYGWINvariable in the SYSTEM environment settings.(Cygwin) 実際の許可は SYSTEM 環境設定の
CYGWIN変数の値に依存して設定されます。(Android) Setting the exec bit on some locations (generally /sdcard) will return true but not actually set the bit.
(Android) 一部の場所 (一般的には /sdcard) への実行ビットの設定は真を返しますが 実際にはビットは設定されません。
(VMS) A mode argument of zero sets permissions to the user's default permission mask rather than disabling all permissions.
(VMS) mode 引数に 0 を指定すると、全ての権限を無効にするのではなく、 ユーザーのデフォルトの権限マスクに設定します。
- chown
-
(Plan 9, RISC OS) Not implemented.
(Plan 9, RISC OS) 実装されていません。
(Win32) Does nothing, but won't fail.
(Win32) 何もしませんが失敗もしません。
(VOS) A little funky, because VOS's notion of ownership is a little funky.
(VOS) VOS での所有者の概念は少し変なので、少し変です。
- chroot
-
(Win32, VMS, Plan 9, RISC OS, VOS) Not implemented.
(Win32, VMS, Plan 9, RISC OS, VOS) 実装されていません。
- crypt
-
(Win32) May not be available if library or source was not provided when building perl.
(Win32) perl のビルド時にライブラリかソースが提供されていないと 利用できないかもしれません。
(Android) Not implemented.
(Android) 実装されていません。
- dbmclose
-
(VMS, Plan 9, VOS) Not implemented.
(VMS, Plan 9, VOS) 実装されていません。
- dbmopen
-
(VMS, Plan 9, VOS) Not implemented.
(VMS, Plan 9, VOS) 実装されていません。
- dump
-
(RISC OS) Not useful.
(RISC OS) 使い道はありません。
(Cygwin, Win32) Not supported.
(Cygwin, Win32) 対応していません。
(VMS) Invokes VMS debugger.
(VMS) VMS デバッガを起動します。
- exec
-
(Win32)
exec LISTwithout the use of indirect object syntax (exec PROGRAM LIST) may fall back to trying the shell if the firstspawn()fails.(Win32) 間接オブジェクト構文 (
exec PROGRAM LIST) を使わないexec LISTは、 最初のspawn()が失敗したときにシェルにフォールバックすることがあります。Note that the list form of exec() is emulated since the Win32 API CreateProcess() accepts a simple string rather than an array of command-line arguments. This may have security implications for your code.
Win32 API CreateProcess() はコマンドライン引数の 配列ではなく単純な文字列を受け付けるので、 リスト形式の exec() はエミュレートされることに注意してください。 これはコードに対してセキュリティ問題を起こすかもしれません。
(SunOS, Solaris, HP-UX) Does not automatically flush output handles on some platforms.
(SunOS, Solaris, HP-UX) 一部のプラットフォームでは出力ハンドルを自動的にフラッシュしません。
- exit
-
(VMS) Emulates Unix
exit(which considersexit 1to indicate an error) by mapping the1toSS$_ABORT(44). This behavior may be overridden with the pragmause vmsish 'exit'. As with the CRTL'sexit()function,exit 0is also mapped to an exit status ofSS$_NORMAL(1); this mapping cannot be overridden. Any other argument toexitis used directly as Perl's exit status. On VMS, unless the future POSIX_EXIT mode is enabled, the exit code should always be a valid VMS exit code and not a generic number. When the POSIX_EXIT mode is enabled, a generic number will be encoded in a method compatible with the C library _POSIX_EXIT macro so that it can be decoded by other programs, particularly ones written in C, like the GNV package.(VMS)
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 で書かれているプログラムでデコードできます。(Solaris)
exitresets file pointers, which is a problem when called from a child process (created byfork) inBEGIN. A workaround is to usePOSIX::_exit.(Solaris)
exitはファイルポインタをリセットするので、BEGIN内で (forkによって作られた) 子プロセスから呼び出されたときに 問題になります。 回避方法はPOSIX::_exitを使うことです。exit unless $Config{archname} =~ /\bsolaris\b/; require POSIX; POSIX::_exit(0); - fcntl
-
(Win32) Not implemented.
(Win32) 実装されていません。
(VMS) Some functions available based on the version of VMS.
(VMS) 一部の関数は VMS 版を基として利用可能です。
- flock
-
(VMS, RISC OS, VOS) Not implemented.
(VMS, RISC OS, VOS) 実装されていません。
- fork
-
(AmigaOS, RISC OS, VMS) Not implemented.
(AmigaOS, RISC OS, VMS) 実装されていません。
(Win32) Emulated using multiple interpreters. See perlfork.
(Win32) 複数のインタプリタを使ってエミュレートされています。 perlfork を参照してください。
(SunOS, Solaris, HP-UX) Does not automatically flush output handles on some platforms.
(SunOS, Solaris, HP-UX) 一部のプラットフォームでは出力ハンドルを自動的にフラッシュしません。
- getlogin
-
(RISC OS) Not implemented.
(RISC OS) 実装されていません。
- getpgrp
-
(Win32, VMS, RISC OS) Not implemented.
(Win32, VMS, RISC OS) 実装されていません。
- getppid
-
(Win32, RISC OS) Not implemented.
(Win32, RISC OS) 実装されていません。
- getpriority
-
(Win32, VMS, RISC OS, VOS) Not implemented.
(Win32, VMS, RISC OS, VOS) 実装されていません。
- getpwnam
-
(Win32) Not implemented.
(Win32) 実装されていません。
(RISC OS) Not useful.
(RISC OS) 使い道はありません。
- getgrnam
-
(Win32, VMS, RISC OS) Not implemented.
(Win32, VMS, RISC OS) 実装されていません。
- getnetbyname
-
(Android, Win32, Plan 9) Not implemented.
(Android, Win32, Plan 9) 実装されていません。
- getpwuid
-
(Win32) Not implemented.
(Win32) 実装されていません。
(RISC OS) Not useful.
(RISC OS) 使い道はありません。
- getgrgid
-
(Win32, VMS, RISC OS) Not implemented.
(Win32, VMS, RISC OS) 実装されていません。
- getnetbyaddr
-
(Android, Win32, Plan 9) Not implemented.
(Android, Win32, Plan 9) 実装されていません。
- getprotobynumber
-
(Android) Not implemented.
(Android) 実装されていません。
- getpwent
-
(Android, Win32) Not implemented.
(Android, Win32) 実装されていません。
- getgrent
-
(Android, Win32, VMS) Not implemented.
(Android, Win32, VMS) 実装されていません。
- gethostbyname
-
(Irix 5)
gethostbyname('localhost')does not work everywhere: you may have to usegethostbyname('127.0.0.1').(Irix 5)
gethostbyname('localhost')はどこでも動作するわけではありません:gethostbyname('127.0.0.1')を使う必要があるかもしれません。 - gethostent
-
(Win32) Not implemented.
(Win32) 実装されていません。
- getnetent
-
(Android, Win32, Plan 9) Not implemented.
(Android, Win32, Plan 9) 実装されていません。
- getprotoent
-
(Android, Win32, Plan 9) Not implemented.
(Android, Win32, Plan 9) 実装されていません。
- getservent
-
(Win32, Plan 9) Not implemented.
(Win32, Plan 9) 実装されていません。
- seekdir
-
(Android) Not implemented.
(Android) 実装されていません。
- sethostent
-
(Android, Win32, Plan 9, RISC OS) Not implemented.
(Android, Win32, Plan 9, RISC OS) 実装されていません。
- setnetent
-
(Win32, Plan 9, RISC OS) Not implemented.
(Win32, Plan 9, RISC OS) 実装されていません。
- setprotoent
-
(Android, Win32, Plan 9, RISC OS) Not implemented.
(Android, Win32, Plan 9, RISC OS) 実装されていません。
- setservent
-
(Plan 9, Win32, RISC OS) Not implemented.
(Plan 9, Win32, RISC OS) 実装されていません。
- endpwent
-
(Win32) Not implemented.
(Win32) 実装されていません。
(Android) Either not implemented or a no-op.
(Android) 実装されていないか何もしないかです。
- endgrent
-
(Android, RISC OS, VMS, Win32) Not implemented.
(Android, RISC OS, VMS, Win32) 実装されていません。
- endhostent
-
(Android, Win32) Not implemented.
(Android, Win32) 実装されていません。
- endnetent
-
(Android, Win32, Plan 9) Not implemented.
(Android, Win32, Plan 9) 実装されていません。
- endprotoent
-
(Android, Win32, Plan 9) Not implemented.
(Android, Win32, Plan 9) 実装されていません。
- endservent
-
(Plan 9, Win32) Not implemented.
(Plan 9, Win32) 実装されていません。
- getsockopt
-
(Plan 9) Not implemented.
(Plan 9) 実装されていません。
- glob
-
This operator is implemented via the
File::Globextension on most platforms. See File::Glob for portability information.この演算子はほとんどのプラットフォームでは
File::Globエクステンションで実装されています。 移植性の情報については File::Glob を参照してください。 - gmtime
-
In theory,
gmtimeis reliable from -2**63 to 2**63-1. However, because work-arounds in the implementation use floating point numbers, it will become inaccurate as the time gets larger. This is a bug and will be fixed in the future.理論的には、
gmtimeは -2**63 から 2**63-1 の範囲で信頼性があります。 しかし、実装で浮動小数点数を使っているので、値が大きくなるにつれて 不正確になります。 これはバグで、将来修正されます。(VOS) Time values are 32-bit quantities.
(VOS) 時刻の値は 32-bit です。
- ioctl
-
(VMS) Not implemented.
(VMS) 実装されていません。
(Win32) Available only for socket handles, and it does what the
ioctlsocket()call in the Winsock API does.(Win32) ソケットハンドルに対してのみ利用可能で、Winsock API の
ioctlsocket()呼び出しですることをします。(RISC OS) Available only for socket handles.
(RISC OS) ソケットハンドルに対してのみ利用可能です。
- kill
-
(RISC OS) Not implemented, hence not useful for taint checking.
(RISC OS) 汚染チェックには有用ではないので、実装されていません。
(Win32)
killdoesn't send a signal to the identified process like it does on Unix platforms. Insteadkill($sig, $pid)terminates the process identified by$pid, and makes it exit immediately with exit status$sig. As in Unix, if$sigis 0 and the specified process exists, it returns true without actually terminating it.(Win32)
killは Unix プラットフォームで行われるように識別されたプロセスへシグナルを 送りません。 代わりにkill($sig, $pid)は$pidで識別されるプロセスを終了させ、 終了コード$sigで直ちに終了させます。 Unix でのように、$sigが 0 で指定されたプロセスが存在するなら、実際には 終了させずに真を返します。(Win32)
kill(-9, $pid)will terminate the process specified by$pidand recursively all child processes owned by it. This is different from the Unix semantics, where the signal will be delivered to all processes in the same process group as the process specified by$pid.(Win32)
kill(-9, $pid)は$pidで指定されたプロセスと、そのプロセスが 所有している全ての子プロセスを再帰的に終了させます。 これは、$pidで指定されたプロセスと同じプロセスグループの全ての プロセスにシグナルを送信する、という Unix での動作と異なります。(VMS) A pid of -1 indicating all processes on the system is not currently supported.
(VMS) pid -1 でシステム上の全てのプロセスを示すというのは現在のところ 対応していません。
- link
-
(RISC OS, VOS) Not implemented.
(RISC OS, VOS) 実装されていません。
(AmigaOS) Link count not updated because hard links are not quite that hard (They are sort of half-way between hard and soft links).
(AmigaOS) ハードリンクは完全にハードではないので、リンクカウントは更新されません (これはハードリンクとソフトリンクの中間のようなものです)。
(Win32) Hard links are implemented on Win32 under NTFS only. They are natively supported on Windows 2000 and later. On Windows NT they are implemented using the Windows POSIX subsystem support and the Perl process will need Administrator or Backup Operator privileges to create hard links.
(Win32) ハードリンクは NTFS の Win32 にのみ実装されています。 これは Windows 2000 以降でネイティブに対応しています。 Windows NT では Windows POSIX サブシステムサポートを使って 実装されていて、Perl プロセスはハードリンクを作るには Administrator または Backup Operator 権限が必要です。
(VMS) Available on 64 bit OpenVMS 8.2 and later.
(VMS) 64 ビット OpenVMS 8.2 以降で利用可能です。
- localtime
-
localtimehas the same range as "gmtime", but because time zone rules change, its accuracy for historical and future times may degrade but usually by no more than an hour.localtimeは "gmtime" と同じ範囲を持ちます; しかしタイムゾーンの 規則は変わるので、過去および未来の精度は劣化するかもしれません; しかし普通は 1 時間以内です。 - lstat
-
(RISC OS) Not implemented.
(RISC OS) 実装されていません。
(Win32) Treats directory junctions as symlinks.
(Win32) ディレクトリジャンクションをシンボリックリンクとして扱います。
- msgctl
- msgget
- msgsnd
- msgrcv
-
(Android, Win32, VMS, Plan 9, RISC OS, VOS) Not implemented.
(Android, Win32, VMS, Plan 9, RISC OS, VOS) 実装されていません。
- open
-
(RISC OS) Open modes
|-and-|are unsupported.(Win32, RISC OS) オープンモード
|-と-|は対応していません。(SunOS, Solaris, HP-UX) Opening a process does not automatically flush output handles on some platforms.
(SunOS, Solaris, HP-UX) プロセスをオープンしたときに一部のプラットフォームでは出力ハンドルを自動的に フラッシュしません。
(Win32) Both of modes
|-and-|are supported, but the list form is emulated since the Win32 API CreateProcess() accepts a simple string rather than an array of arguments. This may have security implications for your code.(Win32)
|-と-|の両方のモードに対応していますが、 Win32 API CreateProcess() はコマンドライン引数の 配列ではなく単純な文字列を受け付けるので、 リスト形式はエミュレートされることに注意してください。 これはコードに対してセキュリティ問題を起こすかもしれません。 - readlink
-
(VMS, RISC OS) Not implemented.
(VMS, RISC OS) 実装されていません。
(Win32) readlink() on a directory junction returns the object name, not a simple path.
(Win32) ディレクトリジャンクションに対する readlink() は、単純なパスではなく オブジェクト名を返します。
- rename
-
(Win32) Can't move directories between directories on different logical volumes.
(Win32) 異なった論理ボリュームのディレクトリの間ではディレクトリは移動できません。
- rewinddir
-
(Win32) Will not cause
readdirto re-read the directory stream. The entries already read before therewinddircall will just be returned again from a cache buffer.(Win32) ディレクトリストリームの再読み込みに
readdirを行いません。rewinddir呼び出しの前に既に読み込まれているエントリは再び キャッシュバッファから返されます。 - select
-
(Win32, VMS) Only implemented on sockets.
(Win32, VMS) ソケットに対してのみ実装されています。
(RISC OS) Only reliable on sockets.
(RISC OS) ソケットに対してのみ信頼できます。
Note that the
select FILEHANDLEform is generally portable.select FILEHANDLE形式は一般的に 移植性があることに注意してください。 - semctl
- semget
- semop
-
(Android, Win32, VMS, RISC OS) Not implemented.
(Android, Win32, VMS, RISC OS) 実装されていません。
- setgrent
-
(Android, VMS, Win32, RISC OS) Not implemented.
(Android, VMS, Win32, RISC OS) 実装されていません。
- setpgrp
-
(Win32, VMS, RISC OS, VOS) Not implemented.
(Win32, VMS, RISC OS, VOS) 実装されていません。
- setpriority
-
(Win32, VMS, RISC OS, VOS) Not implemented.
(Win32, VMS, RISC OS, VOS) 実装されていません。
- setpwent
-
(Android, Win32, RISC OS) Not implemented.
(Android, Win32, RISC OS) 実装されていません。
- setsockopt
-
(Plan 9) Not implemented.
(Plan 9) 実装されていません。
- shmctl
- shmget
- shmread
- shmwrite
-
(Android, Win32, VMS, RISC OS) Not implemented.
(Android, Win32, VMS, RISC OS) 実装されていません。
- sleep
-
(Win32) Emulated using synchronization functions such that it can be interrupted by
alarm, and limited to a maximum of 4294967 seconds, approximately 49 days.(Win32)
alarmで割り込みできるように同期関数を使って エミュレートされていて、最大 4294967 秒、およそ 49 日に制限されています。 - socketpair
-
(RISC OS) Not implemented.
(RISC OS) 実装されていません。
(VMS) Available on 64 bit OpenVMS 8.2 and later.
(VMS) 64 ビット OpenVMS 8.2 以降で利用可能です。
- stat
-
Platforms that do not have
rdev,blksize, orblockswill return these as'', so numeric comparison or manipulation of these fields may cause 'not numeric' warnings.rdev,blksize,blocksがないプラットフォームではこれらは''を 返すので、これらのフィールドの数値での比較や操作は 'not numeric' 警告を 引き起こします。(Mac OS X)
ctimenot supported on UFS.(Mac OS X)
ctimeは UFS では対応していません。(Win32)
ctimeis creation time instead of inode change time.(Win32)
ctimeは i ノード変更時刻ではなく作成時刻です。(VMS)
devandinoare not necessarily reliable.(VMS)
devとinoは信頼できるとは限りません。(RISC OS)
mtime,atimeandctimeall return the last modification time.devandinoare not necessarily reliable.(RISC OS)
mtime,atime,ctimeは全て最終更新時刻を返します。devとinoは信頼できるとは限りません。(OS/2)
dev,rdev,blksize, andblocksare not available.inois not meaningful and will differ between stat calls on the same file.(OS/2)
dev,rdev,blksize,blocksは利用できません。inoは無意味で、同じファイルで stat 呼び出しの間でも異なります。(Cygwin) Some versions of cygwin when doing a
stat("foo")and not finding it may then attempt tostat("foo.exe").(Cygwin) cygwin の一部のバージョンでは、
stat("foo")を実行して、もし 見付からなければstat("foo.exe")を実行しようとします。 - symlink
-
(RISC OS) Not implemented.
(RISC OS) 実装されていません。
(Win32) Requires either elevated permissions or developer mode and a sufficiently recent version of Windows 10. You can check whether the current process has the required privileges using the Win32::IsSymlinkCreationAllowed() function.
(Win32) 昇格した権限か開発者モードと、十分に最近のバージョンの Windows 10 が 必要です。 現在のプロセスが必要な権限を持っているかどうかは Win32::IsSymlinkCreationAllowed() 関数を使って調べられます。
Since Windows needs to know whether the target is a directory or not when creating the link the target Perl will only create the link as a directory link when the target exists and is a directory.
Windows はターゲットへのリンクを作る時にターゲットがディレクトリかどうかを 知る必要があるため、Perl はターゲットが存在していてそれが ディレクトリの場合にのみ、リンクをディレクトリリンクとして作ります。
(VMS) Implemented on 64 bit VMS 8.3. VMS requires the symbolic link to be in Unix syntax if it is intended to resolve to a valid path.
(VMS) 64 ビット VMS 8.3 で実装されています。 VMS は、有効なパスを解決することを目的としているなら、シンボリックリンクが Unix の文法であることが必要です。
- syscall
-
(Win32, VMS, RISC OS, VOS) Not implemented.
(Win32, VMS, RISC OS, VOS) 実装されていません。
- sysopen
-
(Mac OS, OS/390) The traditional
0,1, and2MODEs are implemented with different numeric values on some systems. The flags exported byFcntl(O_RDONLY,O_WRONLY,O_RDWR) should work everywhere though.(Mac OS, OS/390) 伝統的な
0,1,2の MODE は一部のシステムでは異なる数値で 実装されています。 しかし、Fcntlでエクスポートされるフラグ (O_RDONLY,O_WRONLY,O_RDWR) はどこでも動作するはずです。 - system
-
(Win32) As an optimization, may not call the command shell specified in
$ENV{PERL5SHELL}.system(1, @args)spawns an external process and immediately returns its process designator, without waiting for it to terminate. Return value may be used subsequently inwaitorwaitpid. Failure tospawn()a subprocess is indicated by setting$?to255 << 8.$?is set in a way compatible with Unix (i.e. the exit status of the subprocess is obtained by$? >> 8, as described in the documentation).(Win32) 最適化として、
$ENV{PERL5SHELL}で指定されたコマンドシェルを 呼び出さないかもしれません。system(1, @args)は外部プロセスを起動して、その終了を待たず、 直ちにそのプロセス指定子を返します。 返り値は引き続くwaitやwaitpidで使えます。 サブプロセスのspawn()の失敗は、$?に255 << 8を設定することで 示されます。$?は Unix と互換性のある方法 (つまり、サブプロセスの 終了ステータスは文書に記述されている通りに$? >> 8で得られる) で 設定されます。Note that the list form of system() is emulated since the Win32 API CreateProcess() accepts a simple string rather than an array of command-line arguments. This may have security implications for your code.
Win32 API CreateProcess() はコマンドライン引数の 配列ではなく単純な文字列を受け付けるので、 リスト形式の system() はエミュレートされることに注意してください。 これはコードに対してセキュリティ問題を起こすかもしれません。
(RISC OS) There is no shell to process metacharacters, and the native standard is to pass a command line terminated by "\n" "\r" or "\0" to the spawned program. Redirection such as
> foois performed (if at all) by the run time library of the spawned program.system LISTwill call the Unix emulation library'sexecemulation, which attempts to provide emulation of the stdin, stdout, stderr in force in the parent, provided the child program uses a compatible version of the emulation library.system SCALARwill call the native command line directly and no such emulation of a child Unix program will occur. Mileage will vary.(RISC OS) メタ文字を処理するシェルはなく、ネイティブな標準では "\n", "\r", "\0" で終端されたコマンドラインを spawn したプログラムに 渡します。
> fooのようなリダイレクトは spawn したプログラムの ランタイムライブラリによって実行されます。system LISTは Unix エミュレーションライブラリのexecエミュレーションを呼び出し、子プログラムがエミュレーションライブラリの 互換版を使っているなら、親の stdin, stdout, stderr をエミュレーションを 提供しようとします。system SCALARはネイティブなコマンドラインを直接呼び出し、 子 Unix プログラムのエミュレーションは起こりません。 これは状況によって 異なります。(Win32)
system LISTwithout the use of indirect object syntax (system PROGRAM LIST) may fall back to trying the shell if the firstspawn()fails.(Win32) 間接オブジェクト構文 (
system PROGRAM LIST) を使わないsystem LISTは、 最初のspawn()が失敗したときにシェルにフォールバックすることがあります。(SunOS, Solaris, HP-UX) Does not automatically flush output handles on some platforms.
(SunOS, Solaris, HP-UX) 一部のプラットフォームでは出力ハンドルを自動的にフラッシュしません。
(VMS) As with Win32,
system(1, @args)spawns an external process and immediately returns its process designator without waiting for the process to terminate. In this case the return value may be used subsequently inwaitorwaitpid. Otherwise the return value is POSIX-like (shifted up by 8 bits), which only allows room for a made-up value derived from the severity bits of the native 32-bit condition code (unless overridden byuse vmsish 'status'). If the native condition code is one that has a POSIX value encoded, the POSIX value will be decoded to extract the expected exit value. For more details see "$?" in perlvms.(VMS) Win32 と同様、
system(1, @args)は外部プロセスを起動して、 プロセスが修了するのを待たずにプロセス指定者を返します。 この場合、返り値は引き続いてwaitやwaitpidで 使えます。 さもなければ返り値は POSIX 風 (8 ビットシフト) で、 (use vmsish 'status'で 上書きされない限り)ネイティブな 32 ビット条件コードの重大度ビットから 作り上げられた値のための場所だけがあります。 ネイティブな条件コードが POSIX 値をエンコードしたものなら、 POSIX 値は想定される終了コードを展開するためにデコードされます。 さらなる詳細については "$?" in perlvms を参照してください。 - telldir
-
(Android) Not implemented.
(Android) 実装されていません。
- times
-
(Win32) "Cumulative" times will be bogus. On anything other than Windows NT or Windows 2000, "system" time will be bogus, and "user" time is actually the time returned by the
clock()function in the C runtime library.(Win32) 「累積」時間は偽りかもしれません。 Windows NT と Windows 2000 以外では、「システム」時間は偽りかもしれず、 「ユーザ」時間は実際には C ランタイムライブラリの
clock()関数から返された時刻です。(RISC OS) Not useful.
(RISC OS) 使い道はありません。
- truncate
-
(Older versions of VMS) Not implemented.
(古いバージョンの VMS) 実装されていません。
(VOS) Truncation to same-or-shorter lengths only.
(VOS) 同じかより短い長さへの切り詰めのみです。
(Win32) If a FILEHANDLE is supplied, it must be writable and opened in append mode (i.e., use
open(my $fh, '>>', 'filename')orsysopen(my $fh, ..., O_APPEND|O_RDWR). If a filename is supplied, it should not be held open elsewhere.(Win32) FILEHANDLE が指定されると、それは書き込み可能で、追記モード (つまり
open(my $fh, '>>', 'filename')またはsysopen(my $fh, ..., O_APPEND|O_RDWR)を使っている)でなければなりません。 ファイル名が指定されると、他で開いていてはいけません。 - umask
-
Returns
undefwhere unavailable.利用不可能な場合は
undefを返します。(AmigaOS)
umaskworks but the correct permissions are set only when the file is finally closed.(AmigaOS)
umaskは動作しますが、正しい権限はファイルが最終的に閉じられたときにのみ 設定されます。 - utime
-
(VMS, RISC OS) Only the modification time is updated.
(VMS, RISC OS) 修正時刻が更新されたときのみです。
(Win32) May not behave as expected. Behavior depends on the C runtime library's implementation of
utime(), and the filesystem being used. The FAT filesystem typically does not support an "access time" field, and it may limit timestamps to a granularity of two seconds.(Win32) 想定した通りに動作しないかもしれません。 振る舞いは C ランタイムライブラリの
utime()の実装と、使われる ファイルシステムに依存します。 FAT ファイルシステムは典型的には「アクセス時刻」フィールドに 対応しておらず、タイムスタンプの精度が 2 秒に制限されているかも しれません。 - wait
- waitpid
-
(Win32) Can only be applied to process handles returned for processes spawned using
system(1, ...)or pseudo processes created withfork.(Win32)
system(1, ...)を使って作成されたプロセスか、forkで作成された 疑似プロセスで返されたプロセスハンドルに対してのみ適用できます。(RISC OS) Not useful.
(RISC OS) 使い道はありません。
対応しているプラットフォーム¶
The following platforms are known to build Perl 5.12 (as of April 2010, its release date) from the standard source code distribution available at http://www.cpan.org/src
以下のプラットフォームは (リリース日である 2010 年 4 月時点で) http://www.cpan.org/src で利用可能な標準ソースコード配布から Perl 5.12 を ビルドしていることが知られています
- Linux (x86, ARM, IA64)
- HP-UX
- AIX
- Win32
-
- Windows 2000
- Windows XP
- Windows Server 2003
- Windows Vista
- Windows Server 2008
- Windows 7
- Cygwin
-
Some tests are known to fail:
-
ext/XS-APItest/t/call_checker.t - see https://github.com/Perl/perl5/issues/10750
ext/XS-APItest/t/call_checker.t - https://github.com/Perl/perl5/issues/10750 を参照してください。
dist/I18N-Collate/t/I18N-Collate.t
-
ext/Win32CORE/t/win32core.t - may fail on recent cygwin installs.
ext/Win32CORE/t/win32core.t - 最近の cygwin では失敗します。
-
- Solaris (x86, SPARC)
- OpenVMS
-
- Alpha (7.2 and later)
- I64 (8.2 and later)
- NetBSD
- FreeBSD
- Debian GNU/kFreeBSD
- Haiku
- Irix (6.5. What else?)
- OpenBSD
- Dragonfly BSD
- Midnight BSD
- QNX Neutrino RTOS (6.5.0)
- MirOS BSD
- Stratus OpenVOS (17.0 or later)
-
Caveats:
注意:
- time_t issues that may or may not be fixed
-
(time_t の問題は修正されているかもしれませんしされていないかもしれません)
- Stratus VOS / OpenVOS
- AIX
- Android
- FreeMINT
-
Perl now builds with FreeMiNT/Atari. It fails a few tests, that needs some investigation.
Perl は FreeMiNT/Atari でビルド出来るようになりました。 いくつかのテストは失敗するので、調査が必要です。
The FreeMiNT port uses GNU dld for loadable module capabilities. So ensure you have that library installed when building perl.
FreeMiNT 版は読み込み可能モジュール機能のために GNU dld を使っています。 従って、perl をビルドするときにこのライブラリがあることを確認してください。
EOL プラットフォーム¶
(Perl 5.36)¶
The following platforms were supported by a previous version of Perl but have been officially removed from Perl's source code as of 5.36:
以下のプラットフォームは以前のバージョンの Perl では対応していましたが 5.36 の時点で Perl のソースコードから公式に取り除かれました:
- NetWare
- DOS/DJGPP
- AT&T UWIN
(Perl 5.20)¶
The following platforms were supported by a previous version of Perl but have been officially removed from Perl's source code as of 5.20:
以下のプラットフォームは以前のバージョンの Perl では対応していましたが 5.20 の時点で Perl のソースコードから公式に取り除かれました:
- AT&T 3b1
(Perl 5.14)¶
The following platforms were supported up to 5.10. They may still have worked in 5.12, but supporting code has been removed for 5.14:
以下のプラットフォームは 5.10 まで対応していました。 5.12 でもまだ動作していましたが、対応コードは 5.14 で取り除かれました:
- Windows 95
- Windows 98
- Windows ME
- Windows NT4
(Perl 5.12)¶
The following platforms were supported by a previous version of Perl but have been officially removed from Perl's source code as of 5.12:
以下のプラットフォームは以前のバージョンの Perl では対応していましたが 5.12 の時点で Perl のソースコードから公式に取り除かれました:
- Atari MiNT
- Apollo Domain/OS
- Apple Mac OS 8/9
- Tenon Machten
対応していたプラットフォーム (Perl 5.8)¶
As of July 2002 (the Perl release 5.8.0), the following platforms were able to build Perl from the standard source code distribution available at http://www.cpan.org/src/
2002 年 7 月 (Perl リリース 5.8.0) 現在、以下のプラットフォームが http://www.cpan.org/src/ から利用可能な標準ソースコード配布から ビルド可能でした:
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)
POSIX-BC (formerly BS2000)
QNX
Solaris
SunOS 4
SUPER-UX (NEC)
Tru64 UNIX (formerly DEC OSF/1, Digital UNIX)
UNICOS
UNICOS/mk
UTS
VOS / OpenVOS
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), VC6The following platforms worked with the previous releases (5.6 and 5.7), but we did not manage either to fix or to test these in time for the 5.8.0 release. There is a very good chance that many of these will work fine with the 5.8.0.
以下のプラットフォームは以前のリリース (5.6 と 5.7) で動作していましたが、 5.8.0 リリースのときに修正やテストができませんでした。 これらの多くは 5.8.0 でうまく動く可能性がかなりあります。
BSD/OS
DomainOS
Hurd
LynxOS
MachTen
PowerMAX
SCO SV
SVR4
Unixware
Windows 3.1Known to be broken for 5.8.0 (but 5.6.1 and 5.7.2 can be used):
5.8.0 で壊れていることが知られています (しかし 5.6.1 と 5.7.2 は使えます):
AmigaOS 3The following platforms have been known to build Perl from source in the past (5.005_03 and earlier), but we haven't been able to verify their status for the current release, either because the hardware/software platforms are rare or because we don't have an active champion on these platforms--or both. They used to work, though, so go ahead and try compiling them, and let https://github.com/Perl/perl5/issues know of any trouble.
以下のプラットフォームは過去 (5.005_03 以前) にソースから Perl を ビルドしたことが知られていますが、現在のリリースに対する状況を 確認できません; ハードウェア/ソフトウェアプラットフォームがレアなものか、 これらのプラットフォームに対するアクティブな推進者がいないか、 あるいはその両方が理由です。 しかし以前は動いていたので、ぜひコンパイルしてみて、 https://github.com/Perl/perl5/issues に問題点を知らせてください。
3b1
A/UX
ConvexOS
CX/UX
DC/OSx
DDE SMES
DOS EMX
Dynix
EP/IX
ESIX
FPS
GENIX
Greenhills
ISC
MachTen 68k
MPC
NEWS-OS
NextSTEP
OpenSTEP
Opus
Plan 9
RISC/os
SCO ODT/OSR
Stellar
SVR2
TI1500
TitanOS
Ultrix
Unisys DynixThe following platforms have their own source code distributions and binaries available via http://www.cpan.org/ports/
以下のプラットフォームは http://www.cpan.org/ports/ 経由で独自の ソースコード配布とバイナリが利用可能です:
Perl release
OS/400 (ILE) 5.005_02
Tandem Guardian 5.004The following platforms have only binaries available via http://www.cpan.org/ports/index.html :
以下のプラットフォームは http://www.cpan.org/ports/index.html 経由で バイナリのみが利用可能です:
Perl release
Acorn RISCOS 5.005_02
AOS 5.002
LynxOS 5.004_02Although we do suggest that you always build your own Perl from the source code, both for maximal configurability and for security, in case you are in a hurry you can check http://www.cpan.org/ports/index.html for binary distributions.
しかし、私たちは、最大限の設定可能性とセキュリティの両方のために、 常にあなた自身の Perl をソースからビルドすることを提案しています; 急いでいる場合には http://www.cpan.org/ports/index.html にある バイナリ配布をチェックしてください。
SEE ALSO¶
perlaix, perlamiga, perlbs2000, perlcygwin, perlebcdic, perlfreebsd, perlhurd, perlhpux, perlirix, perlmacosx, perlos2, perlos390, perlos400, perlplan9, perlqnx, perlsolaris, perltru64, perlunicode, perlvms, perlvos, perlwin32, and Win32.
perlaix, perlamiga, perlbs2000, perlcygwin, perlebcdic, perlfreebsd, perlhurd, perlhpux, perlirix, perlmacosx, perlos2, perlos390, perlos400, perlplan9, perlqnx, perlsolaris, perltru64, perlunicode, perlvms, perlvos, perlwin32, Win32
AUTHORS / CONTRIBUTORS¶
Abigail <[email protected]>, Charles Bailey <[email protected]>, Graham Barr <[email protected]>, Tom Christiansen <[email protected]>, Nicholas Clark <[email protected]>, Thomas Dorner <[email protected]>, Andy Dougherty <[email protected]>, Dominic Dunlop <[email protected]>, Neale Ferguson <[email protected]>, David J. Fiander <[email protected]>, Paul Green <[email protected]>, M.J.T. Guy <[email protected]>, Jarkko Hietaniemi <[email protected]>, Luther Huffman <[email protected]>, Nick Ing-Simmons <[email protected]>, Andreas J. König <[email protected]>, Markus Laker <[email protected]>, Andrew M. Langmead <[email protected]>, Lukas Mai <[email protected]>, Larry Moore <[email protected]>, Paul Moore <[email protected]>, Chris Nandor <[email protected]>, Matthias Neeracher <[email protected]>, Philip Newton <[email protected]>, Gary Ng <[email protected]>, Tom Phoenix <[email protected]>, André Pirard <[email protected]>, Peter Prymmer <[email protected]>, Hugo van der Sanden <[email protected]>, Gurusamy Sarathy <[email protected]>, Paul J. Schinder <[email protected]>, Michael G Schwern <[email protected]>, Dan Sugalski <[email protected]>, Nathan Torkington <[email protected]>, John Malmberg <[email protected]>