1 | =head1 NAME
|
---|
2 |
|
---|
3 | perlport - Writing portable Perl
|
---|
4 |
|
---|
5 | =head1 DESCRIPTION
|
---|
6 |
|
---|
7 | Perl runs on numerous operating systems. While most of them share
|
---|
8 | much in common, they also have their own unique features.
|
---|
9 |
|
---|
10 | This document is meant to help you to find out what constitutes portable
|
---|
11 | Perl code. That way once you make a decision to write portably,
|
---|
12 | you know where the lines are drawn, and you can stay within them.
|
---|
13 |
|
---|
14 | There is a tradeoff between taking full advantage of one particular
|
---|
15 | type of computer and taking advantage of a full range of them.
|
---|
16 | Naturally, as you broaden your range and become more diverse, the
|
---|
17 | common factors drop, and you are left with an increasingly smaller
|
---|
18 | area of common ground in which you can operate to accomplish a
|
---|
19 | particular task. Thus, when you begin attacking a problem, it is
|
---|
20 | important to consider under which part of the tradeoff curve you
|
---|
21 | want to operate. Specifically, you must decide whether it is
|
---|
22 | important that the task that you are coding have the full generality
|
---|
23 | of being portable, or whether to just get the job done right now.
|
---|
24 | This is the hardest choice to be made. The rest is easy, because
|
---|
25 | Perl provides many choices, whichever way you want to approach your
|
---|
26 | problem.
|
---|
27 |
|
---|
28 | Looking at it another way, writing portable code is usually about
|
---|
29 | willfully limiting your available choices. Naturally, it takes
|
---|
30 | discipline and sacrifice to do that. The product of portability
|
---|
31 | and convenience may be a constant. You have been warned.
|
---|
32 |
|
---|
33 | Be aware of two important points:
|
---|
34 |
|
---|
35 | =over 4
|
---|
36 |
|
---|
37 | =item Not all Perl programs have to be portable
|
---|
38 |
|
---|
39 | There is no reason you should not use Perl as a language to glue Unix
|
---|
40 | tools together, or to prototype a Macintosh application, or to manage the
|
---|
41 | Windows registry. If it makes no sense to aim for portability for one
|
---|
42 | reason or another in a given program, then don't bother.
|
---|
43 |
|
---|
44 | =item Nearly all of Perl already I<is> portable
|
---|
45 |
|
---|
46 | Don't be fooled into thinking that it is hard to create portable Perl
|
---|
47 | code. It isn't. Perl tries its level-best to bridge the gaps between
|
---|
48 | what's available on different platforms, and all the means available to
|
---|
49 | use those features. Thus almost all Perl code runs on any machine
|
---|
50 | without modification. But there are some significant issues in
|
---|
51 | writing portable code, and this document is entirely about those issues.
|
---|
52 |
|
---|
53 | =back
|
---|
54 |
|
---|
55 | Here's the general rule: When you approach a task commonly done
|
---|
56 | using a whole range of platforms, think about writing portable
|
---|
57 | code. That way, you don't sacrifice much by way of the implementation
|
---|
58 | choices you can avail yourself of, and at the same time you can give
|
---|
59 | your users lots of platform choices. On the other hand, when you have to
|
---|
60 | take advantage of some unique feature of a particular platform, as is
|
---|
61 | often the case with systems programming (whether for Unix, Windows,
|
---|
62 | S<Mac OS>, VMS, etc.), consider writing platform-specific code.
|
---|
63 |
|
---|
64 | When the code will run on only two or three operating systems, you
|
---|
65 | may need to consider only the differences of those particular systems.
|
---|
66 | The important thing is to decide where the code will run and to be
|
---|
67 | deliberate in your decision.
|
---|
68 |
|
---|
69 | The material below is separated into three main sections: main issues of
|
---|
70 | portability (L<"ISSUES">), platform-specific issues (L<"PLATFORMS">), and
|
---|
71 | built-in perl functions that behave differently on various ports
|
---|
72 | (L<"FUNCTION IMPLEMENTATIONS">).
|
---|
73 |
|
---|
74 | This information should not be considered complete; it includes possibly
|
---|
75 | transient information about idiosyncrasies of some of the ports, almost
|
---|
76 | all of which are in a state of constant evolution. Thus, this material
|
---|
77 | should be considered a perpetual work in progress
|
---|
78 | (C<< <IMG SRC="yellow_sign.gif" ALT="Under Construction"> >>).
|
---|
79 |
|
---|
80 | =head1 ISSUES
|
---|
81 |
|
---|
82 | =head2 Newlines
|
---|
83 |
|
---|
84 | In most operating systems, lines in files are terminated by newlines.
|
---|
85 | Just what is used as a newline may vary from OS to OS. Unix
|
---|
86 | traditionally uses C<\012>, one type of DOSish I/O uses C<\015\012>,
|
---|
87 | and S<Mac OS> uses C<\015>.
|
---|
88 |
|
---|
89 | Perl uses C<\n> to represent the "logical" newline, where what is
|
---|
90 | logical may depend on the platform in use. In MacPerl, C<\n> always
|
---|
91 | means C<\015>. In DOSish perls, C<\n> usually means C<\012>, but
|
---|
92 | when accessing a file in "text" mode, STDIO translates it to (or
|
---|
93 | from) C<\015\012>, depending on whether you're reading or writing.
|
---|
94 | Unix does the same thing on ttys in canonical mode. C<\015\012>
|
---|
95 | is commonly referred to as CRLF.
|
---|
96 |
|
---|
97 | A common cause of unportable programs is the misuse of chop() to trim
|
---|
98 | newlines:
|
---|
99 |
|
---|
100 | # XXX UNPORTABLE!
|
---|
101 | while(<FILE>) {
|
---|
102 | chop;
|
---|
103 | @array = split(/:/);
|
---|
104 | #...
|
---|
105 | }
|
---|
106 |
|
---|
107 | You can get away with this on Unix and Mac OS (they have a single
|
---|
108 | character end-of-line), but the same program will break under DOSish
|
---|
109 | perls because you're only chop()ing half the end-of-line. Instead,
|
---|
110 | chomp() should be used to trim newlines. The L<Dunce::Files> module
|
---|
111 | can help audit your code for misuses of chop().
|
---|
112 |
|
---|
113 | When dealing with binary files (or text files in binary mode) be sure
|
---|
114 | to explicitly set $/ to the appropriate value for your file format
|
---|
115 | before using chomp().
|
---|
116 |
|
---|
117 | Because of the "text" mode translation, DOSish perls have limitations
|
---|
118 | in using C<seek> and C<tell> on a file accessed in "text" mode.
|
---|
119 | Stick to C<seek>-ing to locations you got from C<tell> (and no
|
---|
120 | others), and you are usually free to use C<seek> and C<tell> even
|
---|
121 | in "text" mode. Using C<seek> or C<tell> or other file operations
|
---|
122 | may be non-portable. If you use C<binmode> on a file, however, you
|
---|
123 | can usually C<seek> and C<tell> with arbitrary values in safety.
|
---|
124 |
|
---|
125 | A common misconception in socket programming is that C<\n> eq C<\012>
|
---|
126 | everywhere. When using protocols such as common Internet protocols,
|
---|
127 | C<\012> and C<\015> are called for specifically, and the values of
|
---|
128 | the logical C<\n> and C<\r> (carriage return) are not reliable.
|
---|
129 |
|
---|
130 | print SOCKET "Hi there, client!\r\n"; # WRONG
|
---|
131 | print SOCKET "Hi there, client!\015\012"; # RIGHT
|
---|
132 |
|
---|
133 | However, using C<\015\012> (or C<\cM\cJ>, or C<\x0D\x0A>) can be tedious
|
---|
134 | and unsightly, as well as confusing to those maintaining the code. As
|
---|
135 | such, the Socket module supplies the Right Thing for those who want it.
|
---|
136 |
|
---|
137 | use Socket qw(:DEFAULT :crlf);
|
---|
138 | print SOCKET "Hi there, client!$CRLF" # RIGHT
|
---|
139 |
|
---|
140 | When reading from a socket, remember that the default input record
|
---|
141 | separator C<$/> is C<\n>, but robust socket code will recognize as
|
---|
142 | either C<\012> or C<\015\012> as end of line:
|
---|
143 |
|
---|
144 | while (<SOCKET>) {
|
---|
145 | # ...
|
---|
146 | }
|
---|
147 |
|
---|
148 | Because both CRLF and LF end in LF, the input record separator can
|
---|
149 | be set to LF and any CR stripped later. Better to write:
|
---|
150 |
|
---|
151 | use Socket qw(:DEFAULT :crlf);
|
---|
152 | local($/) = LF; # not needed if $/ is already \012
|
---|
153 |
|
---|
154 | while (<SOCKET>) {
|
---|
155 | s/$CR?$LF/\n/; # not sure if socket uses LF or CRLF, OK
|
---|
156 | # s/\015?\012/\n/; # same thing
|
---|
157 | }
|
---|
158 |
|
---|
159 | This example is preferred over the previous one--even for Unix
|
---|
160 | platforms--because now any C<\015>'s (C<\cM>'s) are stripped out
|
---|
161 | (and there was much rejoicing).
|
---|
162 |
|
---|
163 | Similarly, functions that return text data--such as a function that
|
---|
164 | fetches a web page--should sometimes translate newlines before
|
---|
165 | returning the data, if they've not yet been translated to the local
|
---|
166 | newline representation. A single line of code will often suffice:
|
---|
167 |
|
---|
168 | $data =~ s/\015?\012/\n/g;
|
---|
169 | return $data;
|
---|
170 |
|
---|
171 | Some of this may be confusing. Here's a handy reference to the ASCII CR
|
---|
172 | and LF characters. You can print it out and stick it in your wallet.
|
---|
173 |
|
---|
174 | LF eq \012 eq \x0A eq \cJ eq chr(10) eq ASCII 10
|
---|
175 | CR eq \015 eq \x0D eq \cM eq chr(13) eq ASCII 13
|
---|
176 |
|
---|
177 | | Unix | DOS | Mac |
|
---|
178 | ---------------------------
|
---|
179 | \n | LF | LF | CR |
|
---|
180 | \r | CR | CR | LF |
|
---|
181 | \n * | LF | CRLF | CR |
|
---|
182 | \r * | CR | CR | LF |
|
---|
183 | ---------------------------
|
---|
184 | * text-mode STDIO
|
---|
185 |
|
---|
186 | The Unix column assumes that you are not accessing a serial line
|
---|
187 | (like a tty) in canonical mode. If you are, then CR on input becomes
|
---|
188 | "\n", and "\n" on output becomes CRLF.
|
---|
189 |
|
---|
190 | These are just the most common definitions of C<\n> and C<\r> in Perl.
|
---|
191 | There may well be others. For example, on an EBCDIC implementation
|
---|
192 | such as z/OS (OS/390) or OS/400 (using the ILE, the PASE is ASCII-based)
|
---|
193 | the above material is similar to "Unix" but the code numbers change:
|
---|
194 |
|
---|
195 | LF eq \025 eq \x15 eq \cU eq chr(21) eq CP-1047 21
|
---|
196 | LF eq \045 eq \x25 eq chr(37) eq CP-0037 37
|
---|
197 | CR eq \015 eq \x0D eq \cM eq chr(13) eq CP-1047 13
|
---|
198 | CR eq \015 eq \x0D eq \cM eq chr(13) eq CP-0037 13
|
---|
199 |
|
---|
200 | | z/OS | OS/400 |
|
---|
201 | ----------------------
|
---|
202 | \n | LF | LF |
|
---|
203 | \r | CR | CR |
|
---|
204 | \n * | LF | LF |
|
---|
205 | \r * | CR | CR |
|
---|
206 | ----------------------
|
---|
207 | * text-mode STDIO
|
---|
208 |
|
---|
209 | =head2 Numbers endianness and Width
|
---|
210 |
|
---|
211 | Different CPUs store integers and floating point numbers in different
|
---|
212 | orders (called I<endianness>) and widths (32-bit and 64-bit being the
|
---|
213 | most common today). This affects your programs when they attempt to transfer
|
---|
214 | numbers in binary format from one CPU architecture to another,
|
---|
215 | usually either "live" via network connection, or by storing the
|
---|
216 | numbers to secondary storage such as a disk file or tape.
|
---|
217 |
|
---|
218 | Conflicting storage orders make utter mess out of the numbers. If a
|
---|
219 | little-endian host (Intel, VAX) stores 0x12345678 (305419896 in
|
---|
220 | decimal), a big-endian host (Motorola, Sparc, PA) reads it as
|
---|
221 | 0x78563412 (2018915346 in decimal). Alpha and MIPS can be either:
|
---|
222 | Digital/Compaq used/uses them in little-endian mode; SGI/Cray uses
|
---|
223 | them in big-endian mode. To avoid this problem in network (socket)
|
---|
224 | connections use the C<pack> and C<unpack> formats C<n> and C<N>, the
|
---|
225 | "network" orders. These are guaranteed to be portable.
|
---|
226 |
|
---|
227 | As of perl 5.8.5, you can also use the C<E<gt>> and C<E<lt>> modifiers
|
---|
228 | to force big- or little-endian byte-order. This is useful if you want
|
---|
229 | to store signed integers or 64-bit integers, for example.
|
---|
230 |
|
---|
231 | You can explore the endianness of your platform by unpacking a
|
---|
232 | data structure packed in native format such as:
|
---|
233 |
|
---|
234 | print unpack("h*", pack("s2", 1, 2)), "\n";
|
---|
235 | # '10002000' on e.g. Intel x86 or Alpha 21064 in little-endian mode
|
---|
236 | # '00100020' on e.g. Motorola 68040
|
---|
237 |
|
---|
238 | If you need to distinguish between endian architectures you could use
|
---|
239 | either of the variables set like so:
|
---|
240 |
|
---|
241 | $is_big_endian = unpack("h*", pack("s", 1)) =~ /01/;
|
---|
242 | $is_little_endian = unpack("h*", pack("s", 1)) =~ /^1/;
|
---|
243 |
|
---|
244 | Differing widths can cause truncation even between platforms of equal
|
---|
245 | endianness. The platform of shorter width loses the upper parts of the
|
---|
246 | number. There is no good solution for this problem except to avoid
|
---|
247 | transferring or storing raw binary numbers.
|
---|
248 |
|
---|
249 | One can circumnavigate both these problems in two ways. Either
|
---|
250 | transfer and store numbers always in text format, instead of raw
|
---|
251 | binary, or else consider using modules like Data::Dumper (included in
|
---|
252 | the standard distribution as of Perl 5.005) and Storable (included as
|
---|
253 | of perl 5.8). Keeping all data as text significantly simplifies matters.
|
---|
254 |
|
---|
255 | The v-strings are portable only up to v2147483647 (0x7FFFFFFF), that's
|
---|
256 | how far EBCDIC, or more precisely UTF-EBCDIC will go.
|
---|
257 |
|
---|
258 | =head2 Files and Filesystems
|
---|
259 |
|
---|
260 | Most platforms these days structure files in a hierarchical fashion.
|
---|
261 | So, it is reasonably safe to assume that all platforms support the
|
---|
262 | notion of a "path" to uniquely identify a file on the system. How
|
---|
263 | that path is really written, though, differs considerably.
|
---|
264 |
|
---|
265 | Although similar, file path specifications differ between Unix,
|
---|
266 | Windows, S<Mac OS>, OS/2, VMS, VOS, S<RISC OS>, and probably others.
|
---|
267 | Unix, for example, is one of the few OSes that has the elegant idea
|
---|
268 | of a single root directory.
|
---|
269 |
|
---|
270 | DOS, OS/2, VMS, VOS, and Windows can work similarly to Unix with C</>
|
---|
271 | as path separator, or in their own idiosyncratic ways (such as having
|
---|
272 | several root directories and various "unrooted" device files such NIL:
|
---|
273 | and LPT:).
|
---|
274 |
|
---|
275 | S<Mac OS> uses C<:> as a path separator instead of C</>.
|
---|
276 |
|
---|
277 | The filesystem may support neither hard links (C<link>) nor
|
---|
278 | symbolic links (C<symlink>, C<readlink>, C<lstat>).
|
---|
279 |
|
---|
280 | The filesystem may support neither access timestamp nor change
|
---|
281 | timestamp (meaning that about the only portable timestamp is the
|
---|
282 | modification timestamp), or one second granularity of any timestamps
|
---|
283 | (e.g. the FAT filesystem limits the time granularity to two seconds).
|
---|
284 |
|
---|
285 | The "inode change timestamp" (the C<-C> filetest) may really be the
|
---|
286 | "creation timestamp" (which it is not in UNIX).
|
---|
287 |
|
---|
288 | VOS perl can emulate Unix filenames with C</> as path separator. The
|
---|
289 | native pathname characters greater-than, less-than, number-sign, and
|
---|
290 | percent-sign are always accepted.
|
---|
291 |
|
---|
292 | S<RISC OS> perl can emulate Unix filenames with C</> as path
|
---|
293 | separator, or go native and use C<.> for path separator and C<:> to
|
---|
294 | signal filesystems and disk names.
|
---|
295 |
|
---|
296 | Don't assume UNIX filesystem access semantics: that read, write,
|
---|
297 | and execute are all the permissions there are, and even if they exist,
|
---|
298 | that their semantics (for example what do r, w, and x mean on
|
---|
299 | a directory) are the UNIX ones. The various UNIX/POSIX compatibility
|
---|
300 | layers usually try to make interfaces like chmod() work, but sometimes
|
---|
301 | there simply is no good mapping.
|
---|
302 |
|
---|
303 | If all this is intimidating, have no (well, maybe only a little)
|
---|
304 | fear. There are modules that can help. The File::Spec modules
|
---|
305 | provide methods to do the Right Thing on whatever platform happens
|
---|
306 | to be running the program.
|
---|
307 |
|
---|
308 | use File::Spec::Functions;
|
---|
309 | chdir(updir()); # go up one directory
|
---|
310 | $file = catfile(curdir(), 'temp', 'file.txt');
|
---|
311 | # on Unix and Win32, './temp/file.txt'
|
---|
312 | # on Mac OS, ':temp:file.txt'
|
---|
313 | # on VMS, '[.temp]file.txt'
|
---|
314 |
|
---|
315 | File::Spec is available in the standard distribution as of version
|
---|
316 | 5.004_05. File::Spec::Functions is only in File::Spec 0.7 and later,
|
---|
317 | and some versions of perl come with version 0.6. If File::Spec
|
---|
318 | is not updated to 0.7 or later, you must use the object-oriented
|
---|
319 | interface from File::Spec (or upgrade File::Spec).
|
---|
320 |
|
---|
321 | In general, production code should not have file paths hardcoded.
|
---|
322 | Making them user-supplied or read from a configuration file is
|
---|
323 | better, keeping in mind that file path syntax varies on different
|
---|
324 | machines.
|
---|
325 |
|
---|
326 | This is especially noticeable in scripts like Makefiles and test suites,
|
---|
327 | which often assume C</> as a path separator for subdirectories.
|
---|
328 |
|
---|
329 | Also of use is File::Basename from the standard distribution, which
|
---|
330 | splits a pathname into pieces (base filename, full path to directory,
|
---|
331 | and file suffix).
|
---|
332 |
|
---|
333 | Even when on a single platform (if you can call Unix a single platform),
|
---|
334 | remember not to count on the existence or the contents of particular
|
---|
335 | system-specific files or directories, like F</etc/passwd>,
|
---|
336 | F</etc/sendmail.conf>, F</etc/resolv.conf>, or even F</tmp/>. For
|
---|
337 | example, F</etc/passwd> may exist but not contain the encrypted
|
---|
338 | passwords, because the system is using some form of enhanced security.
|
---|
339 | Or it may not contain all the accounts, because the system is using NIS.
|
---|
340 | If code does need to rely on such a file, include a description of the
|
---|
341 | file and its format in the code's documentation, then make it easy for
|
---|
342 | the user to override the default location of the file.
|
---|
343 |
|
---|
344 | Don't assume a text file will end with a newline. They should,
|
---|
345 | but people forget.
|
---|
346 |
|
---|
347 | Do not have two files or directories of the same name with different
|
---|
348 | case, like F<test.pl> and F<Test.pl>, as many platforms have
|
---|
349 | case-insensitive (or at least case-forgiving) filenames. Also, try
|
---|
350 | not to have non-word characters (except for C<.>) in the names, and
|
---|
351 | keep them to the 8.3 convention, for maximum portability, onerous a
|
---|
352 | burden though this may appear.
|
---|
353 |
|
---|
354 | Likewise, when using the AutoSplit module, try to keep your functions to
|
---|
355 | 8.3 naming and case-insensitive conventions; or, at the least,
|
---|
356 | make it so the resulting files have a unique (case-insensitively)
|
---|
357 | first 8 characters.
|
---|
358 |
|
---|
359 | Whitespace in filenames is tolerated on most systems, but not all,
|
---|
360 | and even on systems where it might be tolerated, some utilities
|
---|
361 | might become confused by such whitespace.
|
---|
362 |
|
---|
363 | Many systems (DOS, VMS) cannot have more than one C<.> in their filenames.
|
---|
364 |
|
---|
365 | Don't assume C<< > >> won't be the first character of a filename.
|
---|
366 | Always use C<< < >> explicitly to open a file for reading, or even
|
---|
367 | better, use the three-arg version of open, unless you want the user to
|
---|
368 | be able to specify a pipe open.
|
---|
369 |
|
---|
370 | open(FILE, '<', $existing_file) or die $!;
|
---|
371 |
|
---|
372 | If filenames might use strange characters, it is safest to open it
|
---|
373 | with C<sysopen> instead of C<open>. C<open> is magic and can
|
---|
374 | translate characters like C<< > >>, C<< < >>, and C<|>, which may
|
---|
375 | be the wrong thing to do. (Sometimes, though, it's the right thing.)
|
---|
376 | Three-arg open can also help protect against this translation in cases
|
---|
377 | where it is undesirable.
|
---|
378 |
|
---|
379 | Don't use C<:> as a part of a filename since many systems use that for
|
---|
380 | their own semantics (Mac OS Classic for separating pathname components,
|
---|
381 | many networking schemes and utilities for separating the nodename and
|
---|
382 | the pathname, and so on). For the same reasons, avoid C<@>, C<;> and
|
---|
383 | C<|>.
|
---|
384 |
|
---|
385 | Don't assume that in pathnames you can collapse two leading slashes
|
---|
386 | C<//> into one: some networking and clustering filesystems have special
|
---|
387 | semantics for that. Let the operating system to sort it out.
|
---|
388 |
|
---|
389 | The I<portable filename characters> as defined by ANSI C are
|
---|
390 |
|
---|
391 | a b c d e f g h i j k l m n o p q r t u v w x y z
|
---|
392 | A B C D E F G H I J K L M N O P Q R T U V W X Y Z
|
---|
393 | 0 1 2 3 4 5 6 7 8 9
|
---|
394 | . _ -
|
---|
395 |
|
---|
396 | and the "-" shouldn't be the first character. If you want to be
|
---|
397 | hypercorrect, stay case-insensitive and within the 8.3 naming
|
---|
398 | convention (all the files and directories have to be unique within one
|
---|
399 | directory if their names are lowercased and truncated to eight
|
---|
400 | characters before the C<.>, if any, and to three characters after the
|
---|
401 | C<.>, if any). (And do not use C<.>s in directory names.)
|
---|
402 |
|
---|
403 | =head2 System Interaction
|
---|
404 |
|
---|
405 | Not all platforms provide a command line. These are usually platforms
|
---|
406 | that rely primarily on a Graphical User Interface (GUI) for user
|
---|
407 | interaction. A program requiring a command line interface might
|
---|
408 | not work everywhere. This is probably for the user of the program
|
---|
409 | to deal with, so don't stay up late worrying about it.
|
---|
410 |
|
---|
411 | Some platforms can't delete or rename files held open by the system,
|
---|
412 | this limitation may also apply to changing filesystem metainformation
|
---|
413 | like file permissions or owners. Remember to C<close> files when you
|
---|
414 | are done with them. Don't C<unlink> or C<rename> an open file. Don't
|
---|
415 | C<tie> or C<open> a file already tied or opened; C<untie> or C<close>
|
---|
416 | it first.
|
---|
417 |
|
---|
418 | Don't open the same file more than once at a time for writing, as some
|
---|
419 | operating systems put mandatory locks on such files.
|
---|
420 |
|
---|
421 | Don't assume that write/modify permission on a directory gives the
|
---|
422 | right to add or delete files/directories in that directory. That is
|
---|
423 | filesystem specific: in some filesystems you need write/modify
|
---|
424 | permission also (or even just) in the file/directory itself. In some
|
---|
425 | filesystems (AFS, DFS) the permission to add/delete directory entries
|
---|
426 | is a completely separate permission.
|
---|
427 |
|
---|
428 | Don't assume that a single C<unlink> completely gets rid of the file:
|
---|
429 | some filesystems (most notably the ones in VMS) have versioned
|
---|
430 | filesystems, and unlink() removes only the most recent one (it doesn't
|
---|
431 | remove all the versions because by default the native tools on those
|
---|
432 | platforms remove just the most recent version, too). The portable
|
---|
433 | idiom to remove all the versions of a file is
|
---|
434 |
|
---|
435 | 1 while unlink "file";
|
---|
436 |
|
---|
437 | This will terminate if the file is undeleteable for some reason
|
---|
438 | (protected, not there, and so on).
|
---|
439 |
|
---|
440 | Don't count on a specific environment variable existing in C<%ENV>.
|
---|
441 | Don't count on C<%ENV> entries being case-sensitive, or even
|
---|
442 | case-preserving. Don't try to clear %ENV by saying C<%ENV = ();>, or,
|
---|
443 | if you really have to, make it conditional on C<$^O ne 'VMS'> since in
|
---|
444 | VMS the C<%ENV> table is much more than a per-process key-value string
|
---|
445 | table.
|
---|
446 |
|
---|
447 | Don't count on signals or C<%SIG> for anything.
|
---|
448 |
|
---|
449 | Don't count on filename globbing. Use C<opendir>, C<readdir>, and
|
---|
450 | C<closedir> instead.
|
---|
451 |
|
---|
452 | Don't count on per-program environment variables, or per-program current
|
---|
453 | directories.
|
---|
454 |
|
---|
455 | Don't count on specific values of C<$!>, neither numeric nor
|
---|
456 | especially the strings values-- users may switch their locales causing
|
---|
457 | error messages to be translated into their languages. If you can
|
---|
458 | trust a POSIXish environment, you can portably use the symbols defined
|
---|
459 | by the Errno module, like ENOENT. And don't trust on the values of C<$!>
|
---|
460 | at all except immediately after a failed system call.
|
---|
461 |
|
---|
462 | =head2 Command names versus file pathnames
|
---|
463 |
|
---|
464 | Don't assume that the name used to invoke a command or program with
|
---|
465 | C<system> or C<exec> can also be used to test for the existence of the
|
---|
466 | file that holds the executable code for that command or program.
|
---|
467 | First, many systems have "internal" commands that are built-in to the
|
---|
468 | shell or OS and while these commands can be invoked, there is no
|
---|
469 | corresponding file. Second, some operating systems (e.g., Cygwin,
|
---|
470 | DJGPP, OS/2, and VOS) have required suffixes for executable files;
|
---|
471 | these suffixes are generally permitted on the command name but are not
|
---|
472 | required. Thus, a command like "perl" might exist in a file named
|
---|
473 | "perl", "perl.exe", or "perl.pm", depending on the operating system.
|
---|
474 | The variable "_exe" in the Config module holds the executable suffix,
|
---|
475 | if any. Third, the VMS port carefully sets up $^X and
|
---|
476 | $Config{perlpath} so that no further processing is required. This is
|
---|
477 | just as well, because the matching regular expression used below would
|
---|
478 | then have to deal with a possible trailing version number in the VMS
|
---|
479 | file name.
|
---|
480 |
|
---|
481 | To convert $^X to a file pathname, taking account of the requirements
|
---|
482 | of the various operating system possibilities, say:
|
---|
483 |
|
---|
484 | use Config;
|
---|
485 | $thisperl = $^X;
|
---|
486 | if ($^O ne 'VMS')
|
---|
487 | {$thisperl .= $Config{_exe} unless $thisperl =~ m/$Config{_exe}$/i;}
|
---|
488 |
|
---|
489 | To convert $Config{perlpath} to a file pathname, say:
|
---|
490 |
|
---|
491 | use Config;
|
---|
492 | $thisperl = $Config{perlpath};
|
---|
493 | if ($^O ne 'VMS')
|
---|
494 | {$thisperl .= $Config{_exe} unless $thisperl =~ m/$Config{_exe}$/i;}
|
---|
495 |
|
---|
496 | =head2 Networking
|
---|
497 |
|
---|
498 | Don't assume that you can reach the public Internet.
|
---|
499 |
|
---|
500 | Don't assume that there is only one way to get through firewalls
|
---|
501 | to the public Internet.
|
---|
502 |
|
---|
503 | Don't assume that you can reach outside world through any other port
|
---|
504 | than 80, or some web proxy. ftp is blocked by many firewalls.
|
---|
505 |
|
---|
506 | Don't assume that you can send email by connecting to the local SMTP port.
|
---|
507 |
|
---|
508 | Don't assume that you can reach yourself or any node by the name
|
---|
509 | 'localhost'. The same goes for '127.0.0.1'. You will have to try both.
|
---|
510 |
|
---|
511 | Don't assume that the host has only one network card, or that it
|
---|
512 | can't bind to many virtual IP addresses.
|
---|
513 |
|
---|
514 | Don't assume a particular network device name.
|
---|
515 |
|
---|
516 | Don't assume a particular set of ioctl()s will work.
|
---|
517 |
|
---|
518 | Don't assume that you can ping hosts and get replies.
|
---|
519 |
|
---|
520 | Don't assume that any particular port (service) will respond.
|
---|
521 |
|
---|
522 | Don't assume that Sys::Hostname (or any other API or command)
|
---|
523 | returns either a fully qualified hostname or a non-qualified hostname:
|
---|
524 | it all depends on how the system had been configured. Also remember
|
---|
525 | things like DHCP and NAT-- the hostname you get back might not be very
|
---|
526 | useful.
|
---|
527 |
|
---|
528 | All the above "don't":s may look daunting, and they are -- but the key
|
---|
529 | is to degrade gracefully if one cannot reach the particular network
|
---|
530 | service one wants. Croaking or hanging do not look very professional.
|
---|
531 |
|
---|
532 | =head2 Interprocess Communication (IPC)
|
---|
533 |
|
---|
534 | In general, don't directly access the system in code meant to be
|
---|
535 | portable. That means, no C<system>, C<exec>, C<fork>, C<pipe>,
|
---|
536 | C<``>, C<qx//>, C<open> with a C<|>, nor any of the other things
|
---|
537 | that makes being a perl hacker worth being.
|
---|
538 |
|
---|
539 | Commands that launch external processes are generally supported on
|
---|
540 | most platforms (though many of them do not support any type of
|
---|
541 | forking). The problem with using them arises from what you invoke
|
---|
542 | them on. External tools are often named differently on different
|
---|
543 | platforms, may not be available in the same location, might accept
|
---|
544 | different arguments, can behave differently, and often present their
|
---|
545 | results in a platform-dependent way. Thus, you should seldom depend
|
---|
546 | on them to produce consistent results. (Then again, if you're calling
|
---|
547 | I<netstat -a>, you probably don't expect it to run on both Unix and CP/M.)
|
---|
548 |
|
---|
549 | One especially common bit of Perl code is opening a pipe to B<sendmail>:
|
---|
550 |
|
---|
551 | open(MAIL, '|/usr/lib/sendmail -t')
|
---|
552 | or die "cannot fork sendmail: $!";
|
---|
553 |
|
---|
554 | This is fine for systems programming when sendmail is known to be
|
---|
555 | available. But it is not fine for many non-Unix systems, and even
|
---|
556 | some Unix systems that may not have sendmail installed. If a portable
|
---|
557 | solution is needed, see the various distributions on CPAN that deal
|
---|
558 | with it. Mail::Mailer and Mail::Send in the MailTools distribution are
|
---|
559 | commonly used, and provide several mailing methods, including mail,
|
---|
560 | sendmail, and direct SMTP (via Net::SMTP) if a mail transfer agent is
|
---|
561 | not available. Mail::Sendmail is a standalone module that provides
|
---|
562 | simple, platform-independent mailing.
|
---|
563 |
|
---|
564 | The Unix System V IPC (C<msg*(), sem*(), shm*()>) is not available
|
---|
565 | even on all Unix platforms.
|
---|
566 |
|
---|
567 | Do not use either the bare result of C<pack("N", 10, 20, 30, 40)> or
|
---|
568 | bare v-strings (such as C<v10.20.30.40>) to represent IPv4 addresses:
|
---|
569 | both forms just pack the four bytes into network order. That this
|
---|
570 | would be equal to the C language C<in_addr> struct (which is what the
|
---|
571 | socket code internally uses) is not guaranteed. To be portable use
|
---|
572 | the routines of the Socket extension, such as C<inet_aton()>,
|
---|
573 | C<inet_ntoa()>, and C<sockaddr_in()>.
|
---|
574 |
|
---|
575 | The rule of thumb for portable code is: Do it all in portable Perl, or
|
---|
576 | use a module (that may internally implement it with platform-specific
|
---|
577 | code, but expose a common interface).
|
---|
578 |
|
---|
579 | =head2 External Subroutines (XS)
|
---|
580 |
|
---|
581 | XS code can usually be made to work with any platform, but dependent
|
---|
582 | libraries, header files, etc., might not be readily available or
|
---|
583 | portable, or the XS code itself might be platform-specific, just as Perl
|
---|
584 | code might be. If the libraries and headers are portable, then it is
|
---|
585 | normally reasonable to make sure the XS code is portable, too.
|
---|
586 |
|
---|
587 | A different type of portability issue arises when writing XS code:
|
---|
588 | availability of a C compiler on the end-user's system. C brings
|
---|
589 | with it its own portability issues, and writing XS code will expose
|
---|
590 | you to some of those. Writing purely in Perl is an easier way to
|
---|
591 | achieve portability.
|
---|
592 |
|
---|
593 | =head2 Standard Modules
|
---|
594 |
|
---|
595 | In general, the standard modules work across platforms. Notable
|
---|
596 | exceptions are the CPAN module (which currently makes connections to external
|
---|
597 | programs that may not be available), platform-specific modules (like
|
---|
598 | ExtUtils::MM_VMS), and DBM modules.
|
---|
599 |
|
---|
600 | There is no one DBM module available on all platforms.
|
---|
601 | SDBM_File and the others are generally available on all Unix and DOSish
|
---|
602 | ports, but not in MacPerl, where only NBDM_File and DB_File are
|
---|
603 | available.
|
---|
604 |
|
---|
605 | The good news is that at least some DBM module should be available, and
|
---|
606 | AnyDBM_File will use whichever module it can find. Of course, then
|
---|
607 | the code needs to be fairly strict, dropping to the greatest common
|
---|
608 | factor (e.g., not exceeding 1K for each record), so that it will
|
---|
609 | work with any DBM module. See L<AnyDBM_File> for more details.
|
---|
610 |
|
---|
611 | =head2 Time and Date
|
---|
612 |
|
---|
613 | The system's notion of time of day and calendar date is controlled in
|
---|
614 | widely different ways. Don't assume the timezone is stored in C<$ENV{TZ}>,
|
---|
615 | and even if it is, don't assume that you can control the timezone through
|
---|
616 | that variable. Don't assume anything about the three-letter timezone
|
---|
617 | abbreviations (for example that MST would be the Mountain Standard Time,
|
---|
618 | it's been known to stand for Moscow Standard Time). If you need to
|
---|
619 | use timezones, express them in some unambiguous format like the
|
---|
620 | exact number of minutes offset from UTC, or the POSIX timezone
|
---|
621 | format.
|
---|
622 |
|
---|
623 | Don't assume that the epoch starts at 00:00:00, January 1, 1970,
|
---|
624 | because that is OS- and implementation-specific. It is better to
|
---|
625 | store a date in an unambiguous representation. The ISO 8601 standard
|
---|
626 | defines YYYY-MM-DD as the date format, or YYYY-MM-DDTHH-MM-SS
|
---|
627 | (that's a literal "T" separating the date from the time).
|
---|
628 | Please do use the ISO 8601 instead of making us to guess what
|
---|
629 | date 02/03/04 might be. ISO 8601 even sorts nicely as-is.
|
---|
630 | A text representation (like "1987-12-18") can be easily converted
|
---|
631 | into an OS-specific value using a module like Date::Parse.
|
---|
632 | An array of values, such as those returned by C<localtime>, can be
|
---|
633 | converted to an OS-specific representation using Time::Local.
|
---|
634 |
|
---|
635 | When calculating specific times, such as for tests in time or date modules,
|
---|
636 | it may be appropriate to calculate an offset for the epoch.
|
---|
637 |
|
---|
638 | require Time::Local;
|
---|
639 | $offset = Time::Local::timegm(0, 0, 0, 1, 0, 70);
|
---|
640 |
|
---|
641 | The value for C<$offset> in Unix will be C<0>, but in Mac OS will be
|
---|
642 | some large number. C<$offset> can then be added to a Unix time value
|
---|
643 | to get what should be the proper value on any system.
|
---|
644 |
|
---|
645 | On Windows (at least), you shouldn't pass a negative value to C<gmtime> or
|
---|
646 | C<localtime>.
|
---|
647 |
|
---|
648 | =head2 Character sets and character encoding
|
---|
649 |
|
---|
650 | Assume very little about character sets.
|
---|
651 |
|
---|
652 | Assume nothing about numerical values (C<ord>, C<chr>) of characters.
|
---|
653 | Do not use explicit code point ranges (like \xHH-\xHH); use for
|
---|
654 | example symbolic character classes like C<[:print:]>.
|
---|
655 |
|
---|
656 | Do not assume that the alphabetic characters are encoded contiguously
|
---|
657 | (in the numeric sense). There may be gaps.
|
---|
658 |
|
---|
659 | Do not assume anything about the ordering of the characters.
|
---|
660 | The lowercase letters may come before or after the uppercase letters;
|
---|
661 | the lowercase and uppercase may be interlaced so that both "a" and "A"
|
---|
662 | come before "b"; the accented and other international characters may
|
---|
663 | be interlaced so that E<auml> comes before "b".
|
---|
664 |
|
---|
665 | =head2 Internationalisation
|
---|
666 |
|
---|
667 | If you may assume POSIX (a rather large assumption), you may read
|
---|
668 | more about the POSIX locale system from L<perllocale>. The locale
|
---|
669 | system at least attempts to make things a little bit more portable,
|
---|
670 | or at least more convenient and native-friendly for non-English
|
---|
671 | users. The system affects character sets and encoding, and date
|
---|
672 | and time formatting--amongst other things.
|
---|
673 |
|
---|
674 | If you really want to be international, you should consider Unicode.
|
---|
675 | See L<perluniintro> and L<perlunicode> for more information.
|
---|
676 |
|
---|
677 | If you want to use non-ASCII bytes (outside the bytes 0x00..0x7f) in
|
---|
678 | the "source code" of your code, to be portable you have to be explicit
|
---|
679 | about what bytes they are. Someone might for example be using your
|
---|
680 | code under a UTF-8 locale, in which case random native bytes might be
|
---|
681 | illegal ("Malformed UTF-8 ...") This means that for example embedding
|
---|
682 | ISO 8859-1 bytes beyond 0x7f into your strings might cause trouble
|
---|
683 | later. If the bytes are native 8-bit bytes, you can use the C<bytes>
|
---|
684 | pragma. If the bytes are in a string (regular expression being a
|
---|
685 | curious string), you can often also use the C<\xHH> notation instead
|
---|
686 | of embedding the bytes as-is. If they are in some particular legacy
|
---|
687 | encoding (ether single-byte or something more complicated), you can
|
---|
688 | use the C<encoding> pragma. (If you want to write your code in UTF-8,
|
---|
689 | you can use either the C<utf8> pragma, or the C<encoding> pragma.)
|
---|
690 | The C<bytes> and C<utf8> pragmata are available since Perl 5.6.0, and
|
---|
691 | the C<encoding> pragma since Perl 5.8.0.
|
---|
692 |
|
---|
693 | =head2 System Resources
|
---|
694 |
|
---|
695 | If your code is destined for systems with severely constrained (or
|
---|
696 | missing!) virtual memory systems then you want to be I<especially> mindful
|
---|
697 | of avoiding wasteful constructs such as:
|
---|
698 |
|
---|
699 | # NOTE: this is no longer "bad" in perl5.005
|
---|
700 | for (0..10000000) {} # bad
|
---|
701 | for (my $x = 0; $x <= 10000000; ++$x) {} # good
|
---|
702 |
|
---|
703 | @lines = <VERY_LARGE_FILE>; # bad
|
---|
704 |
|
---|
705 | while (<FILE>) {$file .= $_} # sometimes bad
|
---|
706 | $file = join('', <FILE>); # better
|
---|
707 |
|
---|
708 | The last two constructs may appear unintuitive to most people. The
|
---|
709 | first repeatedly grows a string, whereas the second allocates a
|
---|
710 | large chunk of memory in one go. On some systems, the second is
|
---|
711 | more efficient that the first.
|
---|
712 |
|
---|
713 | =head2 Security
|
---|
714 |
|
---|
715 | Most multi-user platforms provide basic levels of security, usually
|
---|
716 | implemented at the filesystem level. Some, however, do
|
---|
717 | not-- unfortunately. Thus the notion of user id, or "home" directory,
|
---|
718 | or even the state of being logged-in, may be unrecognizable on many
|
---|
719 | platforms. If you write programs that are security-conscious, it
|
---|
720 | is usually best to know what type of system you will be running
|
---|
721 | under so that you can write code explicitly for that platform (or
|
---|
722 | class of platforms).
|
---|
723 |
|
---|
724 | Don't assume the UNIX filesystem access semantics: the operating
|
---|
725 | system or the filesystem may be using some ACL systems, which are
|
---|
726 | richer languages than the usual rwx. Even if the rwx exist,
|
---|
727 | their semantics might be different.
|
---|
728 |
|
---|
729 | (From security viewpoint testing for permissions before attempting to
|
---|
730 | do something is silly anyway: if one tries this, there is potential
|
---|
731 | for race conditions-- someone or something might change the
|
---|
732 | permissions between the permissions check and the actual operation.
|
---|
733 | Just try the operation.)
|
---|
734 |
|
---|
735 | Don't assume the UNIX user and group semantics: especially, don't
|
---|
736 | expect the C<< $< >> and C<< $> >> (or the C<$(> and C<$)>) to work
|
---|
737 | for switching identities (or memberships).
|
---|
738 |
|
---|
739 | Don't assume set-uid and set-gid semantics. (And even if you do,
|
---|
740 | think twice: set-uid and set-gid are a known can of security worms.)
|
---|
741 |
|
---|
742 | =head2 Style
|
---|
743 |
|
---|
744 | For those times when it is necessary to have platform-specific code,
|
---|
745 | consider keeping the platform-specific code in one place, making porting
|
---|
746 | to other platforms easier. Use the Config module and the special
|
---|
747 | variable C<$^O> to differentiate platforms, as described in
|
---|
748 | L<"PLATFORMS">.
|
---|
749 |
|
---|
750 | Be careful in the tests you supply with your module or programs.
|
---|
751 | Module code may be fully portable, but its tests might not be. This
|
---|
752 | often happens when tests spawn off other processes or call external
|
---|
753 | programs to aid in the testing, or when (as noted above) the tests
|
---|
754 | assume certain things about the filesystem and paths. Be careful not
|
---|
755 | to depend on a specific output style for errors, such as when checking
|
---|
756 | C<$!> after a failed system call. Using C<$!> for anything else than
|
---|
757 | displaying it as output is doubtful (though see the Errno module for
|
---|
758 | testing reasonably portably for error value). Some platforms expect
|
---|
759 | a certain output format, and Perl on those platforms may have been
|
---|
760 | adjusted accordingly. Most specifically, don't anchor a regex when
|
---|
761 | testing an error value.
|
---|
762 |
|
---|
763 | =head1 CPAN Testers
|
---|
764 |
|
---|
765 | Modules uploaded to CPAN are tested by a variety of volunteers on
|
---|
766 | different platforms. These CPAN testers are notified by mail of each
|
---|
767 | new upload, and reply to the list with PASS, FAIL, NA (not applicable to
|
---|
768 | this platform), or UNKNOWN (unknown), along with any relevant notations.
|
---|
769 |
|
---|
770 | The purpose of the testing is twofold: one, to help developers fix any
|
---|
771 | problems in their code that crop up because of lack of testing on other
|
---|
772 | platforms; two, to provide users with information about whether
|
---|
773 | a given module works on a given platform.
|
---|
774 |
|
---|
775 | Also see:
|
---|
776 |
|
---|
777 | =over 4
|
---|
778 |
|
---|
779 | =item *
|
---|
780 |
|
---|
781 | Mailing list: [email protected]
|
---|
782 |
|
---|
783 | =item *
|
---|
784 |
|
---|
785 | Testing results: http://testers.cpan.org/
|
---|
786 |
|
---|
787 | =back
|
---|
788 |
|
---|
789 | =head1 PLATFORMS
|
---|
790 |
|
---|
791 | As of version 5.002, Perl is built with a C<$^O> variable that
|
---|
792 | indicates the operating system it was built on. This was implemented
|
---|
793 | to help speed up code that would otherwise have to C<use Config>
|
---|
794 | and use the value of C<$Config{osname}>. Of course, to get more
|
---|
795 | detailed information about the system, looking into C<%Config> is
|
---|
796 | certainly recommended.
|
---|
797 |
|
---|
798 | C<%Config> cannot always be trusted, however, because it was built
|
---|
799 | at compile time. If perl was built in one place, then transferred
|
---|
800 | elsewhere, some values may be wrong. The values may even have been
|
---|
801 | edited after the fact.
|
---|
802 |
|
---|
803 | =head2 Unix
|
---|
804 |
|
---|
805 | Perl works on a bewildering variety of Unix and Unix-like platforms (see
|
---|
806 | e.g. most of the files in the F<hints/> directory in the source code kit).
|
---|
807 | On most of these systems, the value of C<$^O> (hence C<$Config{'osname'}>,
|
---|
808 | too) is determined either by lowercasing and stripping punctuation from the
|
---|
809 | first field of the string returned by typing C<uname -a> (or a similar command)
|
---|
810 | at the shell prompt or by testing the file system for the presence of
|
---|
811 | uniquely named files such as a kernel or header file. Here, for example,
|
---|
812 | are a few of the more popular Unix flavors:
|
---|
813 |
|
---|
814 | uname $^O $Config{'archname'}
|
---|
815 | --------------------------------------------
|
---|
816 | AIX aix aix
|
---|
817 | BSD/OS bsdos i386-bsdos
|
---|
818 | Darwin darwin darwin
|
---|
819 | dgux dgux AViiON-dgux
|
---|
820 | DYNIX/ptx dynixptx i386-dynixptx
|
---|
821 | FreeBSD freebsd freebsd-i386
|
---|
822 | Linux linux arm-linux
|
---|
823 | Linux linux i386-linux
|
---|
824 | Linux linux i586-linux
|
---|
825 | Linux linux ppc-linux
|
---|
826 | HP-UX hpux PA-RISC1.1
|
---|
827 | IRIX irix irix
|
---|
828 | Mac OS X darwin darwin
|
---|
829 | MachTen PPC machten powerpc-machten
|
---|
830 | NeXT 3 next next-fat
|
---|
831 | NeXT 4 next OPENSTEP-Mach
|
---|
832 | openbsd openbsd i386-openbsd
|
---|
833 | OSF1 dec_osf alpha-dec_osf
|
---|
834 | reliantunix-n svr4 RM400-svr4
|
---|
835 | SCO_SV sco_sv i386-sco_sv
|
---|
836 | SINIX-N svr4 RM400-svr4
|
---|
837 | sn4609 unicos CRAY_C90-unicos
|
---|
838 | sn6521 unicosmk t3e-unicosmk
|
---|
839 | sn9617 unicos CRAY_J90-unicos
|
---|
840 | SunOS solaris sun4-solaris
|
---|
841 | SunOS solaris i86pc-solaris
|
---|
842 | SunOS4 sunos sun4-sunos
|
---|
843 |
|
---|
844 | Because the value of C<$Config{archname}> may depend on the
|
---|
845 | hardware architecture, it can vary more than the value of C<$^O>.
|
---|
846 |
|
---|
847 | =head2 DOS and Derivatives
|
---|
848 |
|
---|
849 | Perl has long been ported to Intel-style microcomputers running under
|
---|
850 | systems like PC-DOS, MS-DOS, OS/2, and most Windows platforms you can
|
---|
851 | bring yourself to mention (except for Windows CE, if you count that).
|
---|
852 | Users familiar with I<COMMAND.COM> or I<CMD.EXE> style shells should
|
---|
853 | be aware that each of these file specifications may have subtle
|
---|
854 | differences:
|
---|
855 |
|
---|
856 | $filespec0 = "c:/foo/bar/file.txt";
|
---|
857 | $filespec1 = "c:\\foo\\bar\\file.txt";
|
---|
858 | $filespec2 = 'c:\foo\bar\file.txt';
|
---|
859 | $filespec3 = 'c:\\foo\\bar\\file.txt';
|
---|
860 |
|
---|
861 | System calls accept either C</> or C<\> as the path separator.
|
---|
862 | However, many command-line utilities of DOS vintage treat C</> as
|
---|
863 | the option prefix, so may get confused by filenames containing C</>.
|
---|
864 | Aside from calling any external programs, C</> will work just fine,
|
---|
865 | and probably better, as it is more consistent with popular usage,
|
---|
866 | and avoids the problem of remembering what to backwhack and what
|
---|
867 | not to.
|
---|
868 |
|
---|
869 | The DOS FAT filesystem can accommodate only "8.3" style filenames. Under
|
---|
870 | the "case-insensitive, but case-preserving" HPFS (OS/2) and NTFS (NT)
|
---|
871 | filesystems you may have to be careful about case returned with functions
|
---|
872 | like C<readdir> or used with functions like C<open> or C<opendir>.
|
---|
873 |
|
---|
874 | DOS also treats several filenames as special, such as AUX, PRN,
|
---|
875 | NUL, CON, COM1, LPT1, LPT2, etc. Unfortunately, sometimes these
|
---|
876 | filenames won't even work if you include an explicit directory
|
---|
877 | prefix. It is best to avoid such filenames, if you want your code
|
---|
878 | to be portable to DOS and its derivatives. It's hard to know what
|
---|
879 | these all are, unfortunately.
|
---|
880 |
|
---|
881 | Users of these operating systems may also wish to make use of
|
---|
882 | scripts such as I<pl2bat.bat> or I<pl2cmd> to
|
---|
883 | put wrappers around your scripts.
|
---|
884 |
|
---|
885 | Newline (C<\n>) is translated as C<\015\012> by STDIO when reading from
|
---|
886 | and writing to files (see L<"Newlines">). C<binmode(FILEHANDLE)>
|
---|
887 | will keep C<\n> translated as C<\012> for that filehandle. Since it is a
|
---|
888 | no-op on other systems, C<binmode> should be used for cross-platform code
|
---|
889 | that deals with binary data. That's assuming you realize in advance
|
---|
890 | that your data is in binary. General-purpose programs should
|
---|
891 | often assume nothing about their data.
|
---|
892 |
|
---|
893 | The C<$^O> variable and the C<$Config{archname}> values for various
|
---|
894 | DOSish perls are as follows:
|
---|
895 |
|
---|
896 | OS $^O $Config{archname} ID Version
|
---|
897 | --------------------------------------------------------
|
---|
898 | MS-DOS dos ?
|
---|
899 | PC-DOS dos ?
|
---|
900 | OS/2 os2 ?
|
---|
901 | Windows 3.1 ? ? 0 3 01
|
---|
902 | Windows 95 MSWin32 MSWin32-x86 1 4 00
|
---|
903 | Windows 98 MSWin32 MSWin32-x86 1 4 10
|
---|
904 | Windows ME MSWin32 MSWin32-x86 1 ?
|
---|
905 | Windows NT MSWin32 MSWin32-x86 2 4 xx
|
---|
906 | Windows NT MSWin32 MSWin32-ALPHA 2 4 xx
|
---|
907 | Windows NT MSWin32 MSWin32-ppc 2 4 xx
|
---|
908 | Windows 2000 MSWin32 MSWin32-x86 2 5 00
|
---|
909 | Windows XP MSWin32 MSWin32-x86 2 5 01
|
---|
910 | Windows 2003 MSWin32 MSWin32-x86 2 5 02
|
---|
911 | Windows CE MSWin32 ? 3
|
---|
912 | Cygwin cygwin cygwin
|
---|
913 |
|
---|
914 | The various MSWin32 Perl's can distinguish the OS they are running on
|
---|
915 | via the value of the fifth element of the list returned from
|
---|
916 | Win32::GetOSVersion(). For example:
|
---|
917 |
|
---|
918 | if ($^O eq 'MSWin32') {
|
---|
919 | my @os_version_info = Win32::GetOSVersion();
|
---|
920 | print +('3.1','95','NT')[$os_version_info[4]],"\n";
|
---|
921 | }
|
---|
922 |
|
---|
923 | There are also Win32::IsWinNT() and Win32::IsWin95(), try C<perldoc Win32>,
|
---|
924 | and as of libwin32 0.19 (not part of the core Perl distribution)
|
---|
925 | Win32::GetOSName(). The very portable POSIX::uname() will work too:
|
---|
926 |
|
---|
927 | c:\> perl -MPOSIX -we "print join '|', uname"
|
---|
928 | Windows NT|moonru|5.0|Build 2195 (Service Pack 2)|x86
|
---|
929 |
|
---|
930 | Also see:
|
---|
931 |
|
---|
932 | =over 4
|
---|
933 |
|
---|
934 | =item *
|
---|
935 |
|
---|
936 | The djgpp environment for DOS, http://www.delorie.com/djgpp/
|
---|
937 | and L<perldos>.
|
---|
938 |
|
---|
939 | =item *
|
---|
940 |
|
---|
941 | The EMX environment for DOS, OS/2, etc. [email protected],
|
---|
942 | http://www.leo.org/pub/comp/os/os2/leo/gnu/emx+gcc/index.html or
|
---|
943 | ftp://hobbes.nmsu.edu/pub/os2/dev/emx/ Also L<perlos2>.
|
---|
944 |
|
---|
945 | =item *
|
---|
946 |
|
---|
947 | Build instructions for Win32 in L<perlwin32>, or under the Cygnus environment
|
---|
948 | in L<perlcygwin>.
|
---|
949 |
|
---|
950 | =item *
|
---|
951 |
|
---|
952 | The C<Win32::*> modules in L<Win32>.
|
---|
953 |
|
---|
954 | =item *
|
---|
955 |
|
---|
956 | The ActiveState Pages, http://www.activestate.com/
|
---|
957 |
|
---|
958 | =item *
|
---|
959 |
|
---|
960 | The Cygwin environment for Win32; F<README.cygwin> (installed
|
---|
961 | as L<perlcygwin>), http://www.cygwin.com/
|
---|
962 |
|
---|
963 | =item *
|
---|
964 |
|
---|
965 | The U/WIN environment for Win32,
|
---|
966 | http://www.research.att.com/sw/tools/uwin/
|
---|
967 |
|
---|
968 | =item *
|
---|
969 |
|
---|
970 | Build instructions for OS/2, L<perlos2>
|
---|
971 |
|
---|
972 | =back
|
---|
973 |
|
---|
974 | =head2 S<Mac OS>
|
---|
975 |
|
---|
976 | Any module requiring XS compilation is right out for most people, because
|
---|
977 | MacPerl is built using non-free (and non-cheap!) compilers. Some XS
|
---|
978 | modules that can work with MacPerl are built and distributed in binary
|
---|
979 | form on CPAN.
|
---|
980 |
|
---|
981 | Directories are specified as:
|
---|
982 |
|
---|
983 | volume:folder:file for absolute pathnames
|
---|
984 | volume:folder: for absolute pathnames
|
---|
985 | :folder:file for relative pathnames
|
---|
986 | :folder: for relative pathnames
|
---|
987 | :file for relative pathnames
|
---|
988 | file for relative pathnames
|
---|
989 |
|
---|
990 | Files are stored in the directory in alphabetical order. Filenames are
|
---|
991 | limited to 31 characters, and may include any character except for
|
---|
992 | null and C<:>, which is reserved as the path separator.
|
---|
993 |
|
---|
994 | Instead of C<flock>, see C<FSpSetFLock> and C<FSpRstFLock> in the
|
---|
995 | Mac::Files module, or C<chmod(0444, ...)> and C<chmod(0666, ...)>.
|
---|
996 |
|
---|
997 | In the MacPerl application, you can't run a program from the command line;
|
---|
998 | programs that expect C<@ARGV> to be populated can be edited with something
|
---|
999 | like the following, which brings up a dialog box asking for the command
|
---|
1000 | line arguments.
|
---|
1001 |
|
---|
1002 | if (!@ARGV) {
|
---|
1003 | @ARGV = split /\s+/, MacPerl::Ask('Arguments?');
|
---|
1004 | }
|
---|
1005 |
|
---|
1006 | A MacPerl script saved as a "droplet" will populate C<@ARGV> with the full
|
---|
1007 | pathnames of the files dropped onto the script.
|
---|
1008 |
|
---|
1009 | Mac users can run programs under a type of command line interface
|
---|
1010 | under MPW (Macintosh Programmer's Workshop, a free development
|
---|
1011 | environment from Apple). MacPerl was first introduced as an MPW
|
---|
1012 | tool, and MPW can be used like a shell:
|
---|
1013 |
|
---|
1014 | perl myscript.plx some arguments
|
---|
1015 |
|
---|
1016 | ToolServer is another app from Apple that provides access to MPW tools
|
---|
1017 | from MPW and the MacPerl app, which allows MacPerl programs to use
|
---|
1018 | C<system>, backticks, and piped C<open>.
|
---|
1019 |
|
---|
1020 | "S<Mac OS>" is the proper name for the operating system, but the value
|
---|
1021 | in C<$^O> is "MacOS". To determine architecture, version, or whether
|
---|
1022 | the application or MPW tool version is running, check:
|
---|
1023 |
|
---|
1024 | $is_app = $MacPerl::Version =~ /App/;
|
---|
1025 | $is_tool = $MacPerl::Version =~ /MPW/;
|
---|
1026 | ($version) = $MacPerl::Version =~ /^(\S+)/;
|
---|
1027 | $is_ppc = $MacPerl::Architecture eq 'MacPPC';
|
---|
1028 | $is_68k = $MacPerl::Architecture eq 'Mac68K';
|
---|
1029 |
|
---|
1030 | S<Mac OS X>, based on NeXT's OpenStep OS, runs MacPerl natively, under the
|
---|
1031 | "Classic" environment. There is no "Carbon" version of MacPerl to run
|
---|
1032 | under the primary Mac OS X environment. S<Mac OS X> and its Open Source
|
---|
1033 | version, Darwin, both run Unix perl natively.
|
---|
1034 |
|
---|
1035 | Also see:
|
---|
1036 |
|
---|
1037 | =over 4
|
---|
1038 |
|
---|
1039 | =item *
|
---|
1040 |
|
---|
1041 | MacPerl Development, http://dev.macperl.org/ .
|
---|
1042 |
|
---|
1043 | =item *
|
---|
1044 |
|
---|
1045 | The MacPerl Pages, http://www.macperl.com/ .
|
---|
1046 |
|
---|
1047 | =item *
|
---|
1048 |
|
---|
1049 | The MacPerl mailing lists, http://lists.perl.org/ .
|
---|
1050 |
|
---|
1051 | =item *
|
---|
1052 |
|
---|
1053 | MPW, ftp://ftp.apple.com/developer/Tool_Chest/Core_Mac_OS_Tools/
|
---|
1054 |
|
---|
1055 | =back
|
---|
1056 |
|
---|
1057 | =head2 VMS
|
---|
1058 |
|
---|
1059 | Perl on VMS is discussed in L<perlvms> in the perl distribution.
|
---|
1060 | Perl on VMS can accept either VMS- or Unix-style file
|
---|
1061 | specifications as in either of the following:
|
---|
1062 |
|
---|
1063 | $ perl -ne "print if /perl_setup/i" SYS$LOGIN:LOGIN.COM
|
---|
1064 | $ perl -ne "print if /perl_setup/i" /sys$login/login.com
|
---|
1065 |
|
---|
1066 | but not a mixture of both as in:
|
---|
1067 |
|
---|
1068 | $ perl -ne "print if /perl_setup/i" sys$login:/login.com
|
---|
1069 | Can't open sys$login:/login.com: file specification syntax error
|
---|
1070 |
|
---|
1071 | Interacting with Perl from the Digital Command Language (DCL) shell
|
---|
1072 | often requires a different set of quotation marks than Unix shells do.
|
---|
1073 | For example:
|
---|
1074 |
|
---|
1075 | $ perl -e "print ""Hello, world.\n"""
|
---|
1076 | Hello, world.
|
---|
1077 |
|
---|
1078 | There are several ways to wrap your perl scripts in DCL F<.COM> files, if
|
---|
1079 | you are so inclined. For example:
|
---|
1080 |
|
---|
1081 | $ write sys$output "Hello from DCL!"
|
---|
1082 | $ if p1 .eqs. ""
|
---|
1083 | $ then perl -x 'f$environment("PROCEDURE")
|
---|
1084 | $ else perl -x - 'p1 'p2 'p3 'p4 'p5 'p6 'p7 'p8
|
---|
1085 | $ deck/dollars="__END__"
|
---|
1086 | #!/usr/bin/perl
|
---|
1087 |
|
---|
1088 | print "Hello from Perl!\n";
|
---|
1089 |
|
---|
1090 | __END__
|
---|
1091 | $ endif
|
---|
1092 |
|
---|
1093 | Do take care with C<$ ASSIGN/nolog/user SYS$COMMAND: SYS$INPUT> if your
|
---|
1094 | perl-in-DCL script expects to do things like C<< $read = <STDIN>; >>.
|
---|
1095 |
|
---|
1096 | Filenames are in the format "name.extension;version". The maximum
|
---|
1097 | length for filenames is 39 characters, and the maximum length for
|
---|
1098 | extensions is also 39 characters. Version is a number from 1 to
|
---|
1099 | 32767. Valid characters are C</[A-Z0-9$_-]/>.
|
---|
1100 |
|
---|
1101 | VMS's RMS filesystem is case-insensitive and does not preserve case.
|
---|
1102 | C<readdir> returns lowercased filenames, but specifying a file for
|
---|
1103 | opening remains case-insensitive. Files without extensions have a
|
---|
1104 | trailing period on them, so doing a C<readdir> with a file named F<A.;5>
|
---|
1105 | will return F<a.> (though that file could be opened with
|
---|
1106 | C<open(FH, 'A')>).
|
---|
1107 |
|
---|
1108 | RMS had an eight level limit on directory depths from any rooted logical
|
---|
1109 | (allowing 16 levels overall) prior to VMS 7.2. Hence
|
---|
1110 | C<PERL_ROOT:[LIB.2.3.4.5.6.7.8]> is a valid directory specification but
|
---|
1111 | C<PERL_ROOT:[LIB.2.3.4.5.6.7.8.9]> is not. F<Makefile.PL> authors might
|
---|
1112 | have to take this into account, but at least they can refer to the former
|
---|
1113 | as C</PERL_ROOT/lib/2/3/4/5/6/7/8/>.
|
---|
1114 |
|
---|
1115 | The VMS::Filespec module, which gets installed as part of the build
|
---|
1116 | process on VMS, is a pure Perl module that can easily be installed on
|
---|
1117 | non-VMS platforms and can be helpful for conversions to and from RMS
|
---|
1118 | native formats.
|
---|
1119 |
|
---|
1120 | What C<\n> represents depends on the type of file opened. It usually
|
---|
1121 | represents C<\012> but it could also be C<\015>, C<\012>, C<\015\012>,
|
---|
1122 | C<\000>, C<\040>, or nothing depending on the file organization and
|
---|
1123 | record format. The VMS::Stdio module provides access to the
|
---|
1124 | special fopen() requirements of files with unusual attributes on VMS.
|
---|
1125 |
|
---|
1126 | TCP/IP stacks are optional on VMS, so socket routines might not be
|
---|
1127 | implemented. UDP sockets may not be supported.
|
---|
1128 |
|
---|
1129 | The value of C<$^O> on OpenVMS is "VMS". To determine the architecture
|
---|
1130 | that you are running on without resorting to loading all of C<%Config>
|
---|
1131 | you can examine the content of the C<@INC> array like so:
|
---|
1132 |
|
---|
1133 | if (grep(/VMS_AXP/, @INC)) {
|
---|
1134 | print "I'm on Alpha!\n";
|
---|
1135 |
|
---|
1136 | } elsif (grep(/VMS_VAX/, @INC)) {
|
---|
1137 | print "I'm on VAX!\n";
|
---|
1138 |
|
---|
1139 | } else {
|
---|
1140 | print "I'm not so sure about where $^O is...\n";
|
---|
1141 | }
|
---|
1142 |
|
---|
1143 | On VMS, perl determines the UTC offset from the C<SYS$TIMEZONE_DIFFERENTIAL>
|
---|
1144 | logical name. Although the VMS epoch began at 17-NOV-1858 00:00:00.00,
|
---|
1145 | calls to C<localtime> are adjusted to count offsets from
|
---|
1146 | 01-JAN-1970 00:00:00.00, just like Unix.
|
---|
1147 |
|
---|
1148 | Also see:
|
---|
1149 |
|
---|
1150 | =over 4
|
---|
1151 |
|
---|
1152 | =item *
|
---|
1153 |
|
---|
1154 | F<README.vms> (installed as L<README_vms>), L<perlvms>
|
---|
1155 |
|
---|
1156 | =item *
|
---|
1157 |
|
---|
1158 | vmsperl list, [email protected]
|
---|
1159 |
|
---|
1160 | (Put the words C<subscribe vmsperl> in message body.)
|
---|
1161 |
|
---|
1162 | =item *
|
---|
1163 |
|
---|
1164 | vmsperl on the web, http://www.sidhe.org/vmsperl/index.html
|
---|
1165 |
|
---|
1166 | =back
|
---|
1167 |
|
---|
1168 | =head2 VOS
|
---|
1169 |
|
---|
1170 | Perl on VOS is discussed in F<README.vos> in the perl distribution
|
---|
1171 | (installed as L<perlvos>). Perl on VOS can accept either VOS- or
|
---|
1172 | Unix-style file specifications as in either of the following:
|
---|
1173 |
|
---|
1174 | C<< $ perl -ne "print if /perl_setup/i" >system>notices >>
|
---|
1175 | C<< $ perl -ne "print if /perl_setup/i" /system/notices >>
|
---|
1176 |
|
---|
1177 | or even a mixture of both as in:
|
---|
1178 |
|
---|
1179 | C<< $ perl -ne "print if /perl_setup/i" >system/notices >>
|
---|
1180 |
|
---|
1181 | Even though VOS allows the slash character to appear in object
|
---|
1182 | names, because the VOS port of Perl interprets it as a pathname
|
---|
1183 | delimiting character, VOS files, directories, or links whose names
|
---|
1184 | contain a slash character cannot be processed. Such files must be
|
---|
1185 | renamed before they can be processed by Perl. Note that VOS limits
|
---|
1186 | file names to 32 or fewer characters.
|
---|
1187 |
|
---|
1188 | Perl on VOS can be built using two different compilers and two different
|
---|
1189 | versions of the POSIX runtime. The recommended method for building full
|
---|
1190 | Perl is with the GNU C compiler and the generally-available version of
|
---|
1191 | VOS POSIX support. See F<README.vos> (installed as L<perlvos>) for
|
---|
1192 | restrictions that apply when Perl is built using the VOS Standard C
|
---|
1193 | compiler or the alpha version of VOS POSIX support.
|
---|
1194 |
|
---|
1195 | The value of C<$^O> on VOS is "VOS". To determine the architecture that
|
---|
1196 | you are running on without resorting to loading all of C<%Config> you
|
---|
1197 | can examine the content of the @INC array like so:
|
---|
1198 |
|
---|
1199 | if ($^O =~ /VOS/) {
|
---|
1200 | print "I'm on a Stratus box!\n";
|
---|
1201 | } else {
|
---|
1202 | print "I'm not on a Stratus box!\n";
|
---|
1203 | die;
|
---|
1204 | }
|
---|
1205 |
|
---|
1206 | if (grep(/860/, @INC)) {
|
---|
1207 | print "This box is a Stratus XA/R!\n";
|
---|
1208 |
|
---|
1209 | } elsif (grep(/7100/, @INC)) {
|
---|
1210 | print "This box is a Stratus HP 7100 or 8xxx!\n";
|
---|
1211 |
|
---|
1212 | } elsif (grep(/8000/, @INC)) {
|
---|
1213 | print "This box is a Stratus HP 8xxx!\n";
|
---|
1214 |
|
---|
1215 | } else {
|
---|
1216 | print "This box is a Stratus 68K!\n";
|
---|
1217 | }
|
---|
1218 |
|
---|
1219 | Also see:
|
---|
1220 |
|
---|
1221 | =over 4
|
---|
1222 |
|
---|
1223 | =item *
|
---|
1224 |
|
---|
1225 | F<README.vos> (installed as L<perlvos>)
|
---|
1226 |
|
---|
1227 | =item *
|
---|
1228 |
|
---|
1229 | The VOS mailing list.
|
---|
1230 |
|
---|
1231 | There is no specific mailing list for Perl on VOS. You can post
|
---|
1232 | comments to the comp.sys.stratus newsgroup, or subscribe to the general
|
---|
1233 | Stratus mailing list. Send a letter with "subscribe Info-Stratus" in
|
---|
1234 | the message body to [email protected].
|
---|
1235 |
|
---|
1236 | =item *
|
---|
1237 |
|
---|
1238 | VOS Perl on the web at http://ftp.stratus.com/pub/vos/posix/posix.html
|
---|
1239 |
|
---|
1240 | =back
|
---|
1241 |
|
---|
1242 | =head2 EBCDIC Platforms
|
---|
1243 |
|
---|
1244 | Recent versions of Perl have been ported to platforms such as OS/400 on
|
---|
1245 | AS/400 minicomputers as well as OS/390, VM/ESA, and BS2000 for S/390
|
---|
1246 | Mainframes. Such computers use EBCDIC character sets internally (usually
|
---|
1247 | Character Code Set ID 0037 for OS/400 and either 1047 or POSIX-BC for S/390
|
---|
1248 | systems). On the mainframe perl currently works under the "Unix system
|
---|
1249 | services for OS/390" (formerly known as OpenEdition), VM/ESA OpenEdition, or
|
---|
1250 | the BS200 POSIX-BC system (BS2000 is supported in perl 5.6 and greater).
|
---|
1251 | See L<perlos390> for details. Note that for OS/400 there is also a port of
|
---|
1252 | Perl 5.8.1/5.9.0 or later to the PASE which is ASCII-based (as opposed to
|
---|
1253 | ILE which is EBCDIC-based), see L<perlos400>.
|
---|
1254 |
|
---|
1255 | As of R2.5 of USS for OS/390 and Version 2.3 of VM/ESA these Unix
|
---|
1256 | sub-systems do not support the C<#!> shebang trick for script invocation.
|
---|
1257 | Hence, on OS/390 and VM/ESA perl scripts can be executed with a header
|
---|
1258 | similar to the following simple script:
|
---|
1259 |
|
---|
1260 | : # use perl
|
---|
1261 | eval 'exec /usr/local/bin/perl -S $0 ${1+"$@"}'
|
---|
1262 | if 0;
|
---|
1263 | #!/usr/local/bin/perl # just a comment really
|
---|
1264 |
|
---|
1265 | print "Hello from perl!\n";
|
---|
1266 |
|
---|
1267 | OS/390 will support the C<#!> shebang trick in release 2.8 and beyond.
|
---|
1268 | Calls to C<system> and backticks can use POSIX shell syntax on all
|
---|
1269 | S/390 systems.
|
---|
1270 |
|
---|
1271 | On the AS/400, if PERL5 is in your library list, you may need
|
---|
1272 | to wrap your perl scripts in a CL procedure to invoke them like so:
|
---|
1273 |
|
---|
1274 | BEGIN
|
---|
1275 | CALL PGM(PERL5/PERL) PARM('/QOpenSys/hello.pl')
|
---|
1276 | ENDPGM
|
---|
1277 |
|
---|
1278 | This will invoke the perl script F<hello.pl> in the root of the
|
---|
1279 | QOpenSys file system. On the AS/400 calls to C<system> or backticks
|
---|
1280 | must use CL syntax.
|
---|
1281 |
|
---|
1282 | On these platforms, bear in mind that the EBCDIC character set may have
|
---|
1283 | an effect on what happens with some perl functions (such as C<chr>,
|
---|
1284 | C<pack>, C<print>, C<printf>, C<ord>, C<sort>, C<sprintf>, C<unpack>), as
|
---|
1285 | well as bit-fiddling with ASCII constants using operators like C<^>, C<&>
|
---|
1286 | and C<|>, not to mention dealing with socket interfaces to ASCII computers
|
---|
1287 | (see L<"Newlines">).
|
---|
1288 |
|
---|
1289 | Fortunately, most web servers for the mainframe will correctly
|
---|
1290 | translate the C<\n> in the following statement to its ASCII equivalent
|
---|
1291 | (C<\r> is the same under both Unix and OS/390 & VM/ESA):
|
---|
1292 |
|
---|
1293 | print "Content-type: text/html\r\n\r\n";
|
---|
1294 |
|
---|
1295 | The values of C<$^O> on some of these platforms includes:
|
---|
1296 |
|
---|
1297 | uname $^O $Config{'archname'}
|
---|
1298 | --------------------------------------------
|
---|
1299 | OS/390 os390 os390
|
---|
1300 | OS400 os400 os400
|
---|
1301 | POSIX-BC posix-bc BS2000-posix-bc
|
---|
1302 | VM/ESA vmesa vmesa
|
---|
1303 |
|
---|
1304 | Some simple tricks for determining if you are running on an EBCDIC
|
---|
1305 | platform could include any of the following (perhaps all):
|
---|
1306 |
|
---|
1307 | if ("\t" eq "\05") { print "EBCDIC may be spoken here!\n"; }
|
---|
1308 |
|
---|
1309 | if (ord('A') == 193) { print "EBCDIC may be spoken here!\n"; }
|
---|
1310 |
|
---|
1311 | if (chr(169) eq 'z') { print "EBCDIC may be spoken here!\n"; }
|
---|
1312 |
|
---|
1313 | One thing you may not want to rely on is the EBCDIC encoding
|
---|
1314 | of punctuation characters since these may differ from code page to code
|
---|
1315 | page (and once your module or script is rumoured to work with EBCDIC,
|
---|
1316 | folks will want it to work with all EBCDIC character sets).
|
---|
1317 |
|
---|
1318 | Also see:
|
---|
1319 |
|
---|
1320 | =over 4
|
---|
1321 |
|
---|
1322 | =item *
|
---|
1323 |
|
---|
1324 | L<perlos390>, F<README.os390>, F<perlbs2000>, F<README.vmesa>,
|
---|
1325 | L<perlebcdic>.
|
---|
1326 |
|
---|
1327 | =item *
|
---|
1328 |
|
---|
1329 | The [email protected] list is for discussion of porting issues as well as
|
---|
1330 | general usage issues for all EBCDIC Perls. Send a message body of
|
---|
1331 | "subscribe perl-mvs" to [email protected].
|
---|
1332 |
|
---|
1333 | =item *
|
---|
1334 |
|
---|
1335 | AS/400 Perl information at
|
---|
1336 | http://as400.rochester.ibm.com/
|
---|
1337 | as well as on CPAN in the F<ports/> directory.
|
---|
1338 |
|
---|
1339 | =back
|
---|
1340 |
|
---|
1341 | =head2 Acorn RISC OS
|
---|
1342 |
|
---|
1343 | Because Acorns use ASCII with newlines (C<\n>) in text files as C<\012> like
|
---|
1344 | Unix, and because Unix filename emulation is turned on by default,
|
---|
1345 | most simple scripts will probably work "out of the box". The native
|
---|
1346 | filesystem is modular, and individual filesystems are free to be
|
---|
1347 | case-sensitive or insensitive, and are usually case-preserving. Some
|
---|
1348 | native filesystems have name length limits, which file and directory
|
---|
1349 | names are silently truncated to fit. Scripts should be aware that the
|
---|
1350 | standard filesystem currently has a name length limit of B<10>
|
---|
1351 | characters, with up to 77 items in a directory, but other filesystems
|
---|
1352 | may not impose such limitations.
|
---|
1353 |
|
---|
1354 | Native filenames are of the form
|
---|
1355 |
|
---|
1356 | Filesystem#Special_Field::DiskName.$.Directory.Directory.File
|
---|
1357 |
|
---|
1358 | where
|
---|
1359 |
|
---|
1360 | Special_Field is not usually present, but may contain . and $ .
|
---|
1361 | Filesystem =~ m|[A-Za-z0-9_]|
|
---|
1362 | DsicName =~ m|[A-Za-z0-9_/]|
|
---|
1363 | $ represents the root directory
|
---|
1364 | . is the path separator
|
---|
1365 | @ is the current directory (per filesystem but machine global)
|
---|
1366 | ^ is the parent directory
|
---|
1367 | Directory and File =~ m|[^\0- "\.\$\%\&:\@\\^\|\177]+|
|
---|
1368 |
|
---|
1369 | The default filename translation is roughly C<tr|/.|./|;>
|
---|
1370 |
|
---|
1371 | Note that C<"ADFS::HardDisk.$.File" ne 'ADFS::HardDisk.$.File'> and that
|
---|
1372 | the second stage of C<$> interpolation in regular expressions will fall
|
---|
1373 | foul of the C<$.> if scripts are not careful.
|
---|
1374 |
|
---|
1375 | Logical paths specified by system variables containing comma-separated
|
---|
1376 | search lists are also allowed; hence C<System:Modules> is a valid
|
---|
1377 | filename, and the filesystem will prefix C<Modules> with each section of
|
---|
1378 | C<System$Path> until a name is made that points to an object on disk.
|
---|
1379 | Writing to a new file C<System:Modules> would be allowed only if
|
---|
1380 | C<System$Path> contains a single item list. The filesystem will also
|
---|
1381 | expand system variables in filenames if enclosed in angle brackets, so
|
---|
1382 | C<< <System$Dir>.Modules >> would look for the file
|
---|
1383 | S<C<$ENV{'System$Dir'} . 'Modules'>>. The obvious implication of this is
|
---|
1384 | that B<fully qualified filenames can start with C<< <> >>> and should
|
---|
1385 | be protected when C<open> is used for input.
|
---|
1386 |
|
---|
1387 | Because C<.> was in use as a directory separator and filenames could not
|
---|
1388 | be assumed to be unique after 10 characters, Acorn implemented the C
|
---|
1389 | compiler to strip the trailing C<.c> C<.h> C<.s> and C<.o> suffix from
|
---|
1390 | filenames specified in source code and store the respective files in
|
---|
1391 | subdirectories named after the suffix. Hence files are translated:
|
---|
1392 |
|
---|
1393 | foo.h h.foo
|
---|
1394 | C:foo.h C:h.foo (logical path variable)
|
---|
1395 | sys/os.h sys.h.os (C compiler groks Unix-speak)
|
---|
1396 | 10charname.c c.10charname
|
---|
1397 | 10charname.o o.10charname
|
---|
1398 | 11charname_.c c.11charname (assuming filesystem truncates at 10)
|
---|
1399 |
|
---|
1400 | The Unix emulation library's translation of filenames to native assumes
|
---|
1401 | that this sort of translation is required, and it allows a user-defined list
|
---|
1402 | of known suffixes that it will transpose in this fashion. This may
|
---|
1403 | seem transparent, but consider that with these rules C<foo/bar/baz.h>
|
---|
1404 | and C<foo/bar/h/baz> both map to C<foo.bar.h.baz>, and that C<readdir> and
|
---|
1405 | C<glob> cannot and do not attempt to emulate the reverse mapping. Other
|
---|
1406 | C<.>'s in filenames are translated to C</>.
|
---|
1407 |
|
---|
1408 | As implied above, the environment accessed through C<%ENV> is global, and
|
---|
1409 | the convention is that program specific environment variables are of the
|
---|
1410 | form C<Program$Name>. Each filesystem maintains a current directory,
|
---|
1411 | and the current filesystem's current directory is the B<global> current
|
---|
1412 | directory. Consequently, sociable programs don't change the current
|
---|
1413 | directory but rely on full pathnames, and programs (and Makefiles) cannot
|
---|
1414 | assume that they can spawn a child process which can change the current
|
---|
1415 | directory without affecting its parent (and everyone else for that
|
---|
1416 | matter).
|
---|
1417 |
|
---|
1418 | Because native operating system filehandles are global and are currently
|
---|
1419 | allocated down from 255, with 0 being a reserved value, the Unix emulation
|
---|
1420 | library emulates Unix filehandles. Consequently, you can't rely on
|
---|
1421 | passing C<STDIN>, C<STDOUT>, or C<STDERR> to your children.
|
---|
1422 |
|
---|
1423 | The desire of users to express filenames of the form
|
---|
1424 | C<< <Foo$Dir>.Bar >> on the command line unquoted causes problems,
|
---|
1425 | too: C<``> command output capture has to perform a guessing game. It
|
---|
1426 | assumes that a string C<< <[^<>]+\$[^<>]> >> is a
|
---|
1427 | reference to an environment variable, whereas anything else involving
|
---|
1428 | C<< < >> or C<< > >> is redirection, and generally manages to be 99%
|
---|
1429 | right. Of course, the problem remains that scripts cannot rely on any
|
---|
1430 | Unix tools being available, or that any tools found have Unix-like command
|
---|
1431 | line arguments.
|
---|
1432 |
|
---|
1433 | Extensions and XS are, in theory, buildable by anyone using free
|
---|
1434 | tools. In practice, many don't, as users of the Acorn platform are
|
---|
1435 | used to binary distributions. MakeMaker does run, but no available
|
---|
1436 | make currently copes with MakeMaker's makefiles; even if and when
|
---|
1437 | this should be fixed, the lack of a Unix-like shell will cause
|
---|
1438 | problems with makefile rules, especially lines of the form C<cd
|
---|
1439 | sdbm && make all>, and anything using quoting.
|
---|
1440 |
|
---|
1441 | "S<RISC OS>" is the proper name for the operating system, but the value
|
---|
1442 | in C<$^O> is "riscos" (because we don't like shouting).
|
---|
1443 |
|
---|
1444 | =head2 Other perls
|
---|
1445 |
|
---|
1446 | Perl has been ported to many platforms that do not fit into any of
|
---|
1447 | the categories listed above. Some, such as AmigaOS, Atari MiNT,
|
---|
1448 | BeOS, HP MPE/iX, QNX, Plan 9, and VOS, have been well-integrated
|
---|
1449 | into the standard Perl source code kit. You may need to see the
|
---|
1450 | F<ports/> directory on CPAN for information, and possibly binaries,
|
---|
1451 | for the likes of: aos, Atari ST, lynxos, riscos, Novell Netware,
|
---|
1452 | Tandem Guardian, I<etc.> (Yes, we know that some of these OSes may
|
---|
1453 | fall under the Unix category, but we are not a standards body.)
|
---|
1454 |
|
---|
1455 | Some approximate operating system names and their C<$^O> values
|
---|
1456 | in the "OTHER" category include:
|
---|
1457 |
|
---|
1458 | OS $^O $Config{'archname'}
|
---|
1459 | ------------------------------------------
|
---|
1460 | Amiga DOS amigaos m68k-amigos
|
---|
1461 | BeOS beos
|
---|
1462 | MPE/iX mpeix PA-RISC1.1
|
---|
1463 |
|
---|
1464 | See also:
|
---|
1465 |
|
---|
1466 | =over 4
|
---|
1467 |
|
---|
1468 | =item *
|
---|
1469 |
|
---|
1470 | Amiga, F<README.amiga> (installed as L<perlamiga>).
|
---|
1471 |
|
---|
1472 | =item *
|
---|
1473 |
|
---|
1474 | Atari, F<README.mint> and Guido Flohr's web page
|
---|
1475 | http://stud.uni-sb.de/~gufl0000/
|
---|
1476 |
|
---|
1477 | =item *
|
---|
1478 |
|
---|
1479 | Be OS, F<README.beos>
|
---|
1480 |
|
---|
1481 | =item *
|
---|
1482 |
|
---|
1483 | HP 300 MPE/iX, F<README.mpeix> and Mark Bixby's web page
|
---|
1484 | http://www.bixby.org/mark/perlix.html
|
---|
1485 |
|
---|
1486 | =item *
|
---|
1487 |
|
---|
1488 | A free perl5-based PERL.NLM for Novell Netware is available in
|
---|
1489 | precompiled binary and source code form from http://www.novell.com/
|
---|
1490 | as well as from CPAN.
|
---|
1491 |
|
---|
1492 | =item *
|
---|
1493 |
|
---|
1494 | S<Plan 9>, F<README.plan9>
|
---|
1495 |
|
---|
1496 | =back
|
---|
1497 |
|
---|
1498 | =head1 FUNCTION IMPLEMENTATIONS
|
---|
1499 |
|
---|
1500 | Listed below are functions that are either completely unimplemented
|
---|
1501 | or else have been implemented differently on various platforms.
|
---|
1502 | Following each description will be, in parentheses, a list of
|
---|
1503 | platforms that the description applies to.
|
---|
1504 |
|
---|
1505 | The list may well be incomplete, or even wrong in some places. When
|
---|
1506 | in doubt, consult the platform-specific README files in the Perl
|
---|
1507 | source distribution, and any other documentation resources accompanying
|
---|
1508 | a given port.
|
---|
1509 |
|
---|
1510 | Be aware, moreover, that even among Unix-ish systems there are variations.
|
---|
1511 |
|
---|
1512 | For many functions, you can also query C<%Config>, exported by
|
---|
1513 | default from the Config module. For example, to check whether the
|
---|
1514 | platform has the C<lstat> call, check C<$Config{d_lstat}>. See
|
---|
1515 | L<Config> for a full description of available variables.
|
---|
1516 |
|
---|
1517 | =head2 Alphabetical Listing of Perl Functions
|
---|
1518 |
|
---|
1519 | =over 8
|
---|
1520 |
|
---|
1521 | =item -X
|
---|
1522 |
|
---|
1523 | C<-r>, C<-w>, and C<-x> have a limited meaning only; directories
|
---|
1524 | and applications are executable, and there are no uid/gid
|
---|
1525 | considerations. C<-o> is not supported. (S<Mac OS>)
|
---|
1526 |
|
---|
1527 | C<-r>, C<-w>, C<-x>, and C<-o> tell whether the file is accessible,
|
---|
1528 | which may not reflect UIC-based file protections. (VMS)
|
---|
1529 |
|
---|
1530 | C<-s> returns the size of the data fork, not the total size of data fork
|
---|
1531 | plus resource fork. (S<Mac OS>).
|
---|
1532 |
|
---|
1533 | C<-s> by name on an open file will return the space reserved on disk,
|
---|
1534 | rather than the current extent. C<-s> on an open filehandle returns the
|
---|
1535 | current size. (S<RISC OS>)
|
---|
1536 |
|
---|
1537 | C<-R>, C<-W>, C<-X>, C<-O> are indistinguishable from C<-r>, C<-w>,
|
---|
1538 | C<-x>, C<-o>. (S<Mac OS>, Win32, VMS, S<RISC OS>)
|
---|
1539 |
|
---|
1540 | C<-b>, C<-c>, C<-k>, C<-g>, C<-p>, C<-u>, C<-A> are not implemented.
|
---|
1541 | (S<Mac OS>)
|
---|
1542 |
|
---|
1543 | C<-g>, C<-k>, C<-l>, C<-p>, C<-u>, C<-A> are not particularly meaningful.
|
---|
1544 | (Win32, VMS, S<RISC OS>)
|
---|
1545 |
|
---|
1546 | C<-d> is true if passed a device spec without an explicit directory.
|
---|
1547 | (VMS)
|
---|
1548 |
|
---|
1549 | C<-T> and C<-B> are implemented, but might misclassify Mac text files
|
---|
1550 | with foreign characters; this is the case will all platforms, but may
|
---|
1551 | affect S<Mac OS> often. (S<Mac OS>)
|
---|
1552 |
|
---|
1553 | C<-x> (or C<-X>) determine if a file ends in one of the executable
|
---|
1554 | suffixes. C<-S> is meaningless. (Win32)
|
---|
1555 |
|
---|
1556 | C<-x> (or C<-X>) determine if a file has an executable file type.
|
---|
1557 | (S<RISC OS>)
|
---|
1558 |
|
---|
1559 | =item atan2 Y,X
|
---|
1560 |
|
---|
1561 | Due to issues with various CPUs, math libraries, compilers, and standards,
|
---|
1562 | results for C<atan2()> may vary depending on any combination of the above.
|
---|
1563 | Perl attempts to conform to the Open Group/IEEE standards for the results
|
---|
1564 | returned from C<atan2()>, but cannot force the issue if the system Perl is
|
---|
1565 | run on does not allow it. (Tru64, HP-UX 10.20)
|
---|
1566 |
|
---|
1567 | The current version of the standards for C<atan2()> is available at
|
---|
1568 | L<http://www.opengroup.org/onlinepubs/009695399/functions/atan2.html>.
|
---|
1569 |
|
---|
1570 | =item atan2
|
---|
1571 |
|
---|
1572 | Due to issues with various CPUs, math libraries, compilers, and standards,
|
---|
1573 | results for C<atan2()> may vary depending on any combination of the above.
|
---|
1574 | Perl attempts to conform to the Open Group/IEEE standards for the results
|
---|
1575 | returned from C<atan2()>, but cannot force the issue if the system Perl is
|
---|
1576 | run on does not allow it. (Tru64, HP-UX 10.20)
|
---|
1577 |
|
---|
1578 | The current version of the standards for C<atan2()> is available at
|
---|
1579 | L<http://www.opengroup.org/onlinepubs/009695399/functions/atan2.html>.
|
---|
1580 |
|
---|
1581 | =item binmode
|
---|
1582 |
|
---|
1583 | Meaningless. (S<Mac OS>, S<RISC OS>)
|
---|
1584 |
|
---|
1585 | Reopens file and restores pointer; if function fails, underlying
|
---|
1586 | filehandle may be closed, or pointer may be in a different position.
|
---|
1587 | (VMS)
|
---|
1588 |
|
---|
1589 | The value returned by C<tell> may be affected after the call, and
|
---|
1590 | the filehandle may be flushed. (Win32)
|
---|
1591 |
|
---|
1592 | =item chmod
|
---|
1593 |
|
---|
1594 | Only limited meaning. Disabling/enabling write permission is mapped to
|
---|
1595 | locking/unlocking the file. (S<Mac OS>)
|
---|
1596 |
|
---|
1597 | Only good for changing "owner" read-write access, "group", and "other"
|
---|
1598 | bits are meaningless. (Win32)
|
---|
1599 |
|
---|
1600 | Only good for changing "owner" and "other" read-write access. (S<RISC OS>)
|
---|
1601 |
|
---|
1602 | Access permissions are mapped onto VOS access-control list changes. (VOS)
|
---|
1603 |
|
---|
1604 | The actual permissions set depend on the value of the C<CYGWIN>
|
---|
1605 | in the SYSTEM environment settings. (Cygwin)
|
---|
1606 |
|
---|
1607 | =item chown
|
---|
1608 |
|
---|
1609 | Not implemented. (S<Mac OS>, Win32, S<Plan 9>, S<RISC OS>, VOS)
|
---|
1610 |
|
---|
1611 | Does nothing, but won't fail. (Win32)
|
---|
1612 |
|
---|
1613 | =item chroot
|
---|
1614 |
|
---|
1615 | Not implemented. (S<Mac OS>, Win32, VMS, S<Plan 9>, S<RISC OS>, VOS, VM/ESA)
|
---|
1616 |
|
---|
1617 | =item crypt
|
---|
1618 |
|
---|
1619 | May not be available if library or source was not provided when building
|
---|
1620 | perl. (Win32)
|
---|
1621 |
|
---|
1622 | Not implemented. (VOS)
|
---|
1623 |
|
---|
1624 | =item dbmclose
|
---|
1625 |
|
---|
1626 | Not implemented. (VMS, S<Plan 9>, VOS)
|
---|
1627 |
|
---|
1628 | =item dbmopen
|
---|
1629 |
|
---|
1630 | Not implemented. (VMS, S<Plan 9>, VOS)
|
---|
1631 |
|
---|
1632 | =item dump
|
---|
1633 |
|
---|
1634 | Not useful. (S<Mac OS>, S<RISC OS>)
|
---|
1635 |
|
---|
1636 | Not implemented. (Win32)
|
---|
1637 |
|
---|
1638 | Invokes VMS debugger. (VMS)
|
---|
1639 |
|
---|
1640 | =item exec
|
---|
1641 |
|
---|
1642 | Not implemented. (S<Mac OS>)
|
---|
1643 |
|
---|
1644 | Implemented via Spawn. (VM/ESA)
|
---|
1645 |
|
---|
1646 | Does not automatically flush output handles on some platforms.
|
---|
1647 | (SunOS, Solaris, HP-UX)
|
---|
1648 |
|
---|
1649 | =item exit
|
---|
1650 |
|
---|
1651 | Emulates UNIX exit() (which considers C<exit 1> to indicate an error) by
|
---|
1652 | mapping the C<1> to SS$_ABORT (C<44>). This behavior may be overridden
|
---|
1653 | with the pragma C<use vmsish 'exit'>. As with the CRTL's exit()
|
---|
1654 | function, C<exit 0> is also mapped to an exit status of SS$_NORMAL
|
---|
1655 | (C<1>); this mapping cannot be overridden. Any other argument to exit()
|
---|
1656 | is used directly as Perl's exit status. (VMS)
|
---|
1657 |
|
---|
1658 | =item fcntl
|
---|
1659 |
|
---|
1660 | Not implemented. (Win32, VMS)
|
---|
1661 |
|
---|
1662 | =item flock
|
---|
1663 |
|
---|
1664 | Not implemented (S<Mac OS>, VMS, S<RISC OS>, VOS).
|
---|
1665 |
|
---|
1666 | Available only on Windows NT (not on Windows 95). (Win32)
|
---|
1667 |
|
---|
1668 | =item fork
|
---|
1669 |
|
---|
1670 | Not implemented. (S<Mac OS>, AmigaOS, S<RISC OS>, VOS, VM/ESA, VMS)
|
---|
1671 |
|
---|
1672 | Emulated using multiple interpreters. See L<perlfork>. (Win32)
|
---|
1673 |
|
---|
1674 | Does not automatically flush output handles on some platforms.
|
---|
1675 | (SunOS, Solaris, HP-UX)
|
---|
1676 |
|
---|
1677 | =item getlogin
|
---|
1678 |
|
---|
1679 | Not implemented. (S<Mac OS>, S<RISC OS>)
|
---|
1680 |
|
---|
1681 | =item getpgrp
|
---|
1682 |
|
---|
1683 | Not implemented. (S<Mac OS>, Win32, VMS, S<RISC OS>, VOS)
|
---|
1684 |
|
---|
1685 | =item getppid
|
---|
1686 |
|
---|
1687 | Not implemented. (S<Mac OS>, Win32, S<RISC OS>)
|
---|
1688 |
|
---|
1689 | =item getpriority
|
---|
1690 |
|
---|
1691 | Not implemented. (S<Mac OS>, Win32, VMS, S<RISC OS>, VOS, VM/ESA)
|
---|
1692 |
|
---|
1693 | =item getpwnam
|
---|
1694 |
|
---|
1695 | Not implemented. (S<Mac OS>, Win32)
|
---|
1696 |
|
---|
1697 | Not useful. (S<RISC OS>)
|
---|
1698 |
|
---|
1699 | =item getgrnam
|
---|
1700 |
|
---|
1701 | Not implemented. (S<Mac OS>, Win32, VMS, S<RISC OS>)
|
---|
1702 |
|
---|
1703 | =item getnetbyname
|
---|
1704 |
|
---|
1705 | Not implemented. (S<Mac OS>, Win32, S<Plan 9>)
|
---|
1706 |
|
---|
1707 | =item getpwuid
|
---|
1708 |
|
---|
1709 | Not implemented. (S<Mac OS>, Win32)
|
---|
1710 |
|
---|
1711 | Not useful. (S<RISC OS>)
|
---|
1712 |
|
---|
1713 | =item getgrgid
|
---|
1714 |
|
---|
1715 | Not implemented. (S<Mac OS>, Win32, VMS, S<RISC OS>)
|
---|
1716 |
|
---|
1717 | =item getnetbyaddr
|
---|
1718 |
|
---|
1719 | Not implemented. (S<Mac OS>, Win32, S<Plan 9>)
|
---|
1720 |
|
---|
1721 | =item getprotobynumber
|
---|
1722 |
|
---|
1723 | Not implemented. (S<Mac OS>)
|
---|
1724 |
|
---|
1725 | =item getservbyport
|
---|
1726 |
|
---|
1727 | Not implemented. (S<Mac OS>)
|
---|
1728 |
|
---|
1729 | =item getpwent
|
---|
1730 |
|
---|
1731 | Not implemented. (S<Mac OS>, Win32, VM/ESA)
|
---|
1732 |
|
---|
1733 | =item getgrent
|
---|
1734 |
|
---|
1735 | Not implemented. (S<Mac OS>, Win32, VMS, VM/ESA)
|
---|
1736 |
|
---|
1737 | =item gethostbyname
|
---|
1738 |
|
---|
1739 | C<gethostbyname('localhost')> does not work everywhere: you may have
|
---|
1740 | to use C<gethostbyname('127.0.0.1')>. (S<Mac OS>, S<Irix 5>)
|
---|
1741 |
|
---|
1742 | =item gethostent
|
---|
1743 |
|
---|
1744 | Not implemented. (S<Mac OS>, Win32)
|
---|
1745 |
|
---|
1746 | =item getnetent
|
---|
1747 |
|
---|
1748 | Not implemented. (S<Mac OS>, Win32, S<Plan 9>)
|
---|
1749 |
|
---|
1750 | =item getprotoent
|
---|
1751 |
|
---|
1752 | Not implemented. (S<Mac OS>, Win32, S<Plan 9>)
|
---|
1753 |
|
---|
1754 | =item getservent
|
---|
1755 |
|
---|
1756 | Not implemented. (Win32, S<Plan 9>)
|
---|
1757 |
|
---|
1758 | =item sethostent
|
---|
1759 |
|
---|
1760 | Not implemented. (S<Mac OS>, Win32, S<Plan 9>, S<RISC OS>)
|
---|
1761 |
|
---|
1762 | =item setnetent
|
---|
1763 |
|
---|
1764 | Not implemented. (S<Mac OS>, Win32, S<Plan 9>, S<RISC OS>)
|
---|
1765 |
|
---|
1766 | =item setprotoent
|
---|
1767 |
|
---|
1768 | Not implemented. (S<Mac OS>, Win32, S<Plan 9>, S<RISC OS>)
|
---|
1769 |
|
---|
1770 | =item setservent
|
---|
1771 |
|
---|
1772 | Not implemented. (S<Plan 9>, Win32, S<RISC OS>)
|
---|
1773 |
|
---|
1774 | =item endpwent
|
---|
1775 |
|
---|
1776 | Not implemented. (S<Mac OS>, MPE/iX, VM/ESA, Win32)
|
---|
1777 |
|
---|
1778 | =item endgrent
|
---|
1779 |
|
---|
1780 | Not implemented. (S<Mac OS>, MPE/iX, S<RISC OS>, VM/ESA, VMS, Win32)
|
---|
1781 |
|
---|
1782 | =item endhostent
|
---|
1783 |
|
---|
1784 | Not implemented. (S<Mac OS>, Win32)
|
---|
1785 |
|
---|
1786 | =item endnetent
|
---|
1787 |
|
---|
1788 | Not implemented. (S<Mac OS>, Win32, S<Plan 9>)
|
---|
1789 |
|
---|
1790 | =item endprotoent
|
---|
1791 |
|
---|
1792 | Not implemented. (S<Mac OS>, Win32, S<Plan 9>)
|
---|
1793 |
|
---|
1794 | =item endservent
|
---|
1795 |
|
---|
1796 | Not implemented. (S<Plan 9>, Win32)
|
---|
1797 |
|
---|
1798 | =item getsockopt SOCKET,LEVEL,OPTNAME
|
---|
1799 |
|
---|
1800 | Not implemented. (S<Plan 9>)
|
---|
1801 |
|
---|
1802 | =item glob
|
---|
1803 |
|
---|
1804 | This operator is implemented via the File::Glob extension on most
|
---|
1805 | platforms. See L<File::Glob> for portability information.
|
---|
1806 |
|
---|
1807 | =item gmtime
|
---|
1808 |
|
---|
1809 | Same portability caveats as L<localtime>.
|
---|
1810 |
|
---|
1811 | =item ioctl FILEHANDLE,FUNCTION,SCALAR
|
---|
1812 |
|
---|
1813 | Not implemented. (VMS)
|
---|
1814 |
|
---|
1815 | Available only for socket handles, and it does what the ioctlsocket() call
|
---|
1816 | in the Winsock API does. (Win32)
|
---|
1817 |
|
---|
1818 | Available only for socket handles. (S<RISC OS>)
|
---|
1819 |
|
---|
1820 | =item kill
|
---|
1821 |
|
---|
1822 | C<kill(0, LIST)> is implemented for the sake of taint checking;
|
---|
1823 | use with other signals is unimplemented. (S<Mac OS>)
|
---|
1824 |
|
---|
1825 | Not implemented, hence not useful for taint checking. (S<RISC OS>)
|
---|
1826 |
|
---|
1827 | C<kill()> doesn't have the semantics of C<raise()>, i.e. it doesn't send
|
---|
1828 | a signal to the identified process like it does on Unix platforms.
|
---|
1829 | Instead C<kill($sig, $pid)> terminates the process identified by $pid,
|
---|
1830 | and makes it exit immediately with exit status $sig. As in Unix, if
|
---|
1831 | $sig is 0 and the specified process exists, it returns true without
|
---|
1832 | actually terminating it. (Win32)
|
---|
1833 |
|
---|
1834 | =item link
|
---|
1835 |
|
---|
1836 | Not implemented. (S<Mac OS>, MPE/iX, VMS, S<RISC OS>)
|
---|
1837 |
|
---|
1838 | Link count not updated because hard links are not quite that hard
|
---|
1839 | (They are sort of half-way between hard and soft links). (AmigaOS)
|
---|
1840 |
|
---|
1841 | Hard links are implemented on Win32 (Windows NT and Windows 2000)
|
---|
1842 | under NTFS only.
|
---|
1843 |
|
---|
1844 | =item localtime
|
---|
1845 |
|
---|
1846 | Because Perl currently relies on the native standard C localtime()
|
---|
1847 | function, it is only safe to use times between 0 and (2**31)-1. Times
|
---|
1848 | outside this range may result in unexpected behavior depending on your
|
---|
1849 | operating system's implementation of localtime().
|
---|
1850 |
|
---|
1851 | =item lstat
|
---|
1852 |
|
---|
1853 | Not implemented. (VMS, S<RISC OS>)
|
---|
1854 |
|
---|
1855 | Return values (especially for device and inode) may be bogus. (Win32)
|
---|
1856 |
|
---|
1857 | =item msgctl
|
---|
1858 |
|
---|
1859 | =item msgget
|
---|
1860 |
|
---|
1861 | =item msgsnd
|
---|
1862 |
|
---|
1863 | =item msgrcv
|
---|
1864 |
|
---|
1865 | Not implemented. (S<Mac OS>, Win32, VMS, S<Plan 9>, S<RISC OS>, VOS)
|
---|
1866 |
|
---|
1867 | =item open
|
---|
1868 |
|
---|
1869 | The C<|> variants are supported only if ToolServer is installed.
|
---|
1870 | (S<Mac OS>)
|
---|
1871 |
|
---|
1872 | open to C<|-> and C<-|> are unsupported. (S<Mac OS>, Win32, S<RISC OS>)
|
---|
1873 |
|
---|
1874 | Opening a process does not automatically flush output handles on some
|
---|
1875 | platforms. (SunOS, Solaris, HP-UX)
|
---|
1876 |
|
---|
1877 | =item pipe
|
---|
1878 |
|
---|
1879 | Very limited functionality. (MiNT)
|
---|
1880 |
|
---|
1881 | =item readlink
|
---|
1882 |
|
---|
1883 | Not implemented. (Win32, VMS, S<RISC OS>)
|
---|
1884 |
|
---|
1885 | =item rename
|
---|
1886 |
|
---|
1887 | Can't move directories between directories on different logical volumes. (Win32)
|
---|
1888 |
|
---|
1889 | =item select
|
---|
1890 |
|
---|
1891 | Only implemented on sockets. (Win32, VMS)
|
---|
1892 |
|
---|
1893 | Only reliable on sockets. (S<RISC OS>)
|
---|
1894 |
|
---|
1895 | Note that the C<select FILEHANDLE> form is generally portable.
|
---|
1896 |
|
---|
1897 | =item semctl
|
---|
1898 |
|
---|
1899 | =item semget
|
---|
1900 |
|
---|
1901 | =item semop
|
---|
1902 |
|
---|
1903 | Not implemented. (S<Mac OS>, Win32, VMS, S<RISC OS>, VOS)
|
---|
1904 |
|
---|
1905 | =item setgrent
|
---|
1906 |
|
---|
1907 | Not implemented. (S<Mac OS>, MPE/iX, VMS, Win32, S<RISC OS>)
|
---|
1908 |
|
---|
1909 | =item setpgrp
|
---|
1910 |
|
---|
1911 | Not implemented. (S<Mac OS>, Win32, VMS, S<RISC OS>, VOS)
|
---|
1912 |
|
---|
1913 | =item setpriority
|
---|
1914 |
|
---|
1915 | Not implemented. (S<Mac OS>, Win32, VMS, S<RISC OS>, VOS)
|
---|
1916 |
|
---|
1917 | =item setpwent
|
---|
1918 |
|
---|
1919 | Not implemented. (S<Mac OS>, MPE/iX, Win32, S<RISC OS>)
|
---|
1920 |
|
---|
1921 | =item setsockopt
|
---|
1922 |
|
---|
1923 | Not implemented. (S<Plan 9>)
|
---|
1924 |
|
---|
1925 | =item shmctl
|
---|
1926 |
|
---|
1927 | =item shmget
|
---|
1928 |
|
---|
1929 | =item shmread
|
---|
1930 |
|
---|
1931 | =item shmwrite
|
---|
1932 |
|
---|
1933 | Not implemented. (S<Mac OS>, Win32, VMS, S<RISC OS>, VOS)
|
---|
1934 |
|
---|
1935 | =item sockatmark
|
---|
1936 |
|
---|
1937 | A relatively recent addition to socket functions, may not
|
---|
1938 | be implemented even in UNIX platforms.
|
---|
1939 |
|
---|
1940 | =item socketpair
|
---|
1941 |
|
---|
1942 | Not implemented. (Win32, VMS, S<RISC OS>, VOS, VM/ESA)
|
---|
1943 |
|
---|
1944 | =item stat
|
---|
1945 |
|
---|
1946 | Platforms that do not have rdev, blksize, or blocks will return these
|
---|
1947 | as '', so numeric comparison or manipulation of these fields may cause
|
---|
1948 | 'not numeric' warnings.
|
---|
1949 |
|
---|
1950 | mtime and atime are the same thing, and ctime is creation time instead of
|
---|
1951 | inode change time. (S<Mac OS>).
|
---|
1952 |
|
---|
1953 | ctime not supported on UFS (S<Mac OS X>).
|
---|
1954 |
|
---|
1955 | ctime is creation time instead of inode change time (Win32).
|
---|
1956 |
|
---|
1957 | device and inode are not meaningful. (Win32)
|
---|
1958 |
|
---|
1959 | device and inode are not necessarily reliable. (VMS)
|
---|
1960 |
|
---|
1961 | mtime, atime and ctime all return the last modification time. Device and
|
---|
1962 | inode are not necessarily reliable. (S<RISC OS>)
|
---|
1963 |
|
---|
1964 | dev, rdev, blksize, and blocks are not available. inode is not
|
---|
1965 | meaningful and will differ between stat calls on the same file. (os2)
|
---|
1966 |
|
---|
1967 | some versions of cygwin when doing a stat("foo") and if not finding it
|
---|
1968 | may then attempt to stat("foo.exe") (Cygwin)
|
---|
1969 |
|
---|
1970 | =item symlink
|
---|
1971 |
|
---|
1972 | Not implemented. (Win32, VMS, S<RISC OS>)
|
---|
1973 |
|
---|
1974 | =item syscall
|
---|
1975 |
|
---|
1976 | Not implemented. (S<Mac OS>, Win32, VMS, S<RISC OS>, VOS, VM/ESA)
|
---|
1977 |
|
---|
1978 | =item sysopen
|
---|
1979 |
|
---|
1980 | The traditional "0", "1", and "2" MODEs are implemented with different
|
---|
1981 | numeric values on some systems. The flags exported by C<Fcntl>
|
---|
1982 | (O_RDONLY, O_WRONLY, O_RDWR) should work everywhere though. (S<Mac
|
---|
1983 | OS>, OS/390, VM/ESA)
|
---|
1984 |
|
---|
1985 | =item system
|
---|
1986 |
|
---|
1987 | In general, do not assume the UNIX/POSIX semantics that you can shift
|
---|
1988 | C<$?> right by eight to get the exit value, or that C<$? & 127>
|
---|
1989 | would give you the number of the signal that terminated the program,
|
---|
1990 | or that C<$? & 128> would test true if the program was terminated by a
|
---|
1991 | coredump. Instead, use the POSIX W*() interfaces: for example, use
|
---|
1992 | WIFEXITED($?) and WEXITVALUE($?) to test for a normal exit and the exit
|
---|
1993 | value, WIFSIGNALED($?) and WTERMSIG($?) for a signal exit and the
|
---|
1994 | signal. Core dumping is not a portable concept, so there's no portable
|
---|
1995 | way to test for that.
|
---|
1996 |
|
---|
1997 | Only implemented if ToolServer is installed. (S<Mac OS>)
|
---|
1998 |
|
---|
1999 | As an optimization, may not call the command shell specified in
|
---|
2000 | C<$ENV{PERL5SHELL}>. C<system(1, @args)> spawns an external
|
---|
2001 | process and immediately returns its process designator, without
|
---|
2002 | waiting for it to terminate. Return value may be used subsequently
|
---|
2003 | in C<wait> or C<waitpid>. Failure to spawn() a subprocess is indicated
|
---|
2004 | by setting $? to "255 << 8". C<$?> is set in a way compatible with
|
---|
2005 | Unix (i.e. the exitstatus of the subprocess is obtained by "$? >> 8",
|
---|
2006 | as described in the documentation). (Win32)
|
---|
2007 |
|
---|
2008 | There is no shell to process metacharacters, and the native standard is
|
---|
2009 | to pass a command line terminated by "\n" "\r" or "\0" to the spawned
|
---|
2010 | program. Redirection such as C<< > foo >> is performed (if at all) by
|
---|
2011 | the run time library of the spawned program. C<system> I<list> will call
|
---|
2012 | the Unix emulation library's C<exec> emulation, which attempts to provide
|
---|
2013 | emulation of the stdin, stdout, stderr in force in the parent, providing
|
---|
2014 | the child program uses a compatible version of the emulation library.
|
---|
2015 | I<scalar> will call the native command line direct and no such emulation
|
---|
2016 | of a child Unix program will exists. Mileage B<will> vary. (S<RISC OS>)
|
---|
2017 |
|
---|
2018 | Far from being POSIX compliant. Because there may be no underlying
|
---|
2019 | /bin/sh tries to work around the problem by forking and execing the
|
---|
2020 | first token in its argument string. Handles basic redirection
|
---|
2021 | ("<" or ">") on its own behalf. (MiNT)
|
---|
2022 |
|
---|
2023 | Does not automatically flush output handles on some platforms.
|
---|
2024 | (SunOS, Solaris, HP-UX)
|
---|
2025 |
|
---|
2026 | The return value is POSIX-like (shifted up by 8 bits), which only allows
|
---|
2027 | room for a made-up value derived from the severity bits of the native
|
---|
2028 | 32-bit condition code (unless overridden by C<use vmsish 'status'>).
|
---|
2029 | For more details see L<perlvms/$?>. (VMS)
|
---|
2030 |
|
---|
2031 | =item times
|
---|
2032 |
|
---|
2033 | Only the first entry returned is nonzero. (S<Mac OS>)
|
---|
2034 |
|
---|
2035 | "cumulative" times will be bogus. On anything other than Windows NT
|
---|
2036 | or Windows 2000, "system" time will be bogus, and "user" time is
|
---|
2037 | actually the time returned by the clock() function in the C runtime
|
---|
2038 | library. (Win32)
|
---|
2039 |
|
---|
2040 | Not useful. (S<RISC OS>)
|
---|
2041 |
|
---|
2042 | =item truncate
|
---|
2043 |
|
---|
2044 | Not implemented. (Older versions of VMS)
|
---|
2045 |
|
---|
2046 | Truncation to zero-length only. (VOS)
|
---|
2047 |
|
---|
2048 | If a FILEHANDLE is supplied, it must be writable and opened in append
|
---|
2049 | mode (i.e., use C<<< open(FH, '>>filename') >>>
|
---|
2050 | or C<sysopen(FH,...,O_APPEND|O_RDWR)>. If a filename is supplied, it
|
---|
2051 | should not be held open elsewhere. (Win32)
|
---|
2052 |
|
---|
2053 | =item umask
|
---|
2054 |
|
---|
2055 | Returns undef where unavailable, as of version 5.005.
|
---|
2056 |
|
---|
2057 | C<umask> works but the correct permissions are set only when the file
|
---|
2058 | is finally closed. (AmigaOS)
|
---|
2059 |
|
---|
2060 | =item utime
|
---|
2061 |
|
---|
2062 | Only the modification time is updated. (S<BeOS>, S<Mac OS>, VMS, S<RISC OS>)
|
---|
2063 |
|
---|
2064 | May not behave as expected. Behavior depends on the C runtime
|
---|
2065 | library's implementation of utime(), and the filesystem being
|
---|
2066 | used. The FAT filesystem typically does not support an "access
|
---|
2067 | time" field, and it may limit timestamps to a granularity of
|
---|
2068 | two seconds. (Win32)
|
---|
2069 |
|
---|
2070 | =item wait
|
---|
2071 |
|
---|
2072 | =item waitpid
|
---|
2073 |
|
---|
2074 | Not implemented. (S<Mac OS>, VOS)
|
---|
2075 |
|
---|
2076 | Can only be applied to process handles returned for processes spawned
|
---|
2077 | using C<system(1, ...)> or pseudo processes created with C<fork()>. (Win32)
|
---|
2078 |
|
---|
2079 | Not useful. (S<RISC OS>)
|
---|
2080 |
|
---|
2081 | =back
|
---|
2082 |
|
---|
2083 |
|
---|
2084 | =head1 Supported Platforms
|
---|
2085 |
|
---|
2086 | As of September 2003 (the Perl release 5.8.1), the following platforms
|
---|
2087 | are able to build Perl from the standard source code distribution
|
---|
2088 | available at http://www.cpan.org/src/index.html
|
---|
2089 |
|
---|
2090 | AIX
|
---|
2091 | BeOS
|
---|
2092 | BSD/OS (BSDi)
|
---|
2093 | Cygwin
|
---|
2094 | DG/UX
|
---|
2095 | DOS DJGPP 1)
|
---|
2096 | DYNIX/ptx
|
---|
2097 | EPOC R5
|
---|
2098 | FreeBSD
|
---|
2099 | HI-UXMPP (Hitachi) (5.8.0 worked but we didn't know it)
|
---|
2100 | HP-UX
|
---|
2101 | IRIX
|
---|
2102 | Linux
|
---|
2103 | LynxOS
|
---|
2104 | Mac OS Classic
|
---|
2105 | Mac OS X (Darwin)
|
---|
2106 | MPE/iX
|
---|
2107 | NetBSD
|
---|
2108 | NetWare
|
---|
2109 | NonStop-UX
|
---|
2110 | ReliantUNIX (formerly SINIX)
|
---|
2111 | OpenBSD
|
---|
2112 | OpenVMS (formerly VMS)
|
---|
2113 | Open UNIX (Unixware) (since Perl 5.8.1/5.9.0)
|
---|
2114 | OS/2
|
---|
2115 | OS/400 (using the PASE) (since Perl 5.8.1/5.9.0)
|
---|
2116 | PowerUX
|
---|
2117 | POSIX-BC (formerly BS2000)
|
---|
2118 | QNX
|
---|
2119 | Solaris
|
---|
2120 | SunOS 4
|
---|
2121 | SUPER-UX (NEC)
|
---|
2122 | SVR4
|
---|
2123 | Tru64 UNIX (formerly DEC OSF/1, Digital UNIX)
|
---|
2124 | UNICOS
|
---|
2125 | UNICOS/mk
|
---|
2126 | UTS
|
---|
2127 | VOS
|
---|
2128 | Win95/98/ME/2K/XP 2)
|
---|
2129 | WinCE
|
---|
2130 | z/OS (formerly OS/390)
|
---|
2131 | VM/ESA
|
---|
2132 |
|
---|
2133 | 1) in DOS mode either the DOS or OS/2 ports can be used
|
---|
2134 | 2) compilers: Borland, MinGW (GCC), VC6
|
---|
2135 |
|
---|
2136 | The following platforms worked with the previous releases (5.6 and
|
---|
2137 | 5.7), but we did not manage either to fix or to test these in time
|
---|
2138 | for the 5.8.1 release. There is a very good chance that many of these
|
---|
2139 | will work fine with the 5.8.1.
|
---|
2140 |
|
---|
2141 | DomainOS
|
---|
2142 | Hurd
|
---|
2143 | MachTen
|
---|
2144 | PowerMAX
|
---|
2145 | SCO SV
|
---|
2146 | Unixware
|
---|
2147 | Windows 3.1
|
---|
2148 |
|
---|
2149 | Known to be broken for 5.8.0 and 5.8.1 (but 5.6.1 and 5.7.2 can be used):
|
---|
2150 |
|
---|
2151 | AmigaOS
|
---|
2152 |
|
---|
2153 | The following platforms have been known to build Perl from source in
|
---|
2154 | the past (5.005_03 and earlier), but we haven't been able to verify
|
---|
2155 | their status for the current release, either because the
|
---|
2156 | hardware/software platforms are rare or because we don't have an
|
---|
2157 | active champion on these platforms--or both. They used to work,
|
---|
2158 | though, so go ahead and try compiling them, and let [email protected]
|
---|
2159 | of any trouble.
|
---|
2160 |
|
---|
2161 | 3b1
|
---|
2162 | A/UX
|
---|
2163 | ConvexOS
|
---|
2164 | CX/UX
|
---|
2165 | DC/OSx
|
---|
2166 | DDE SMES
|
---|
2167 | DOS EMX
|
---|
2168 | Dynix
|
---|
2169 | EP/IX
|
---|
2170 | ESIX
|
---|
2171 | FPS
|
---|
2172 | GENIX
|
---|
2173 | Greenhills
|
---|
2174 | ISC
|
---|
2175 | MachTen 68k
|
---|
2176 | MiNT
|
---|
2177 | MPC
|
---|
2178 | NEWS-OS
|
---|
2179 | NextSTEP
|
---|
2180 | OpenSTEP
|
---|
2181 | Opus
|
---|
2182 | Plan 9
|
---|
2183 | RISC/os
|
---|
2184 | SCO ODT/OSR
|
---|
2185 | Stellar
|
---|
2186 | SVR2
|
---|
2187 | TI1500
|
---|
2188 | TitanOS
|
---|
2189 | Ultrix
|
---|
2190 | Unisys Dynix
|
---|
2191 |
|
---|
2192 | The following platforms have their own source code distributions and
|
---|
2193 | binaries available via http://www.cpan.org/ports/
|
---|
2194 |
|
---|
2195 | Perl release
|
---|
2196 |
|
---|
2197 | OS/400 (ILE) 5.005_02
|
---|
2198 | Tandem Guardian 5.004
|
---|
2199 |
|
---|
2200 | The following platforms have only binaries available via
|
---|
2201 | http://www.cpan.org/ports/index.html :
|
---|
2202 |
|
---|
2203 | Perl release
|
---|
2204 |
|
---|
2205 | Acorn RISCOS 5.005_02
|
---|
2206 | AOS 5.002
|
---|
2207 | LynxOS 5.004_02
|
---|
2208 |
|
---|
2209 | Although we do suggest that you always build your own Perl from
|
---|
2210 | the source code, both for maximal configurability and for security,
|
---|
2211 | in case you are in a hurry you can check
|
---|
2212 | http://www.cpan.org/ports/index.html for binary distributions.
|
---|
2213 |
|
---|
2214 | =head1 SEE ALSO
|
---|
2215 |
|
---|
2216 | L<perlaix>, L<perlamiga>, L<perlapollo>, L<perlbeos>, L<perlbs2000>,
|
---|
2217 | L<perlce>, L<perlcygwin>, L<perldgux>, L<perldos>, L<perlepoc>,
|
---|
2218 | L<perlebcdic>, L<perlfreebsd>, L<perlhurd>, L<perlhpux>, L<perlirix>,
|
---|
2219 | L<perlmachten>, L<perlmacos>, L<perlmacosx>, L<perlmint>, L<perlmpeix>,
|
---|
2220 | L<perlnetware>, L<perlos2>, L<perlos390>, L<perlos400>,
|
---|
2221 | L<perlplan9>, L<perlqnx>, L<perlsolaris>, L<perltru64>,
|
---|
2222 | L<perlunicode>, L<perlvmesa>, L<perlvms>, L<perlvos>,
|
---|
2223 | L<perlwin32>, and L<Win32>.
|
---|
2224 |
|
---|
2225 | =head1 AUTHORS / CONTRIBUTORS
|
---|
2226 |
|
---|
2227 | Abigail <[email protected]>,
|
---|
2228 | Charles Bailey <[email protected]>,
|
---|
2229 | Graham Barr <[email protected]>,
|
---|
2230 | Tom Christiansen <[email protected]>,
|
---|
2231 | Nicholas Clark <[email protected]>,
|
---|
2232 | Thomas Dorner <[email protected]>,
|
---|
2233 | Andy Dougherty <[email protected]>,
|
---|
2234 | Dominic Dunlop <[email protected]>,
|
---|
2235 | Neale Ferguson <[email protected]>,
|
---|
2236 | David J. Fiander <[email protected]>,
|
---|
2237 | Paul Green <[email protected]>,
|
---|
2238 | M.J.T. Guy <[email protected]>,
|
---|
2239 | Jarkko Hietaniemi <[email protected]>,
|
---|
2240 | Luther Huffman <[email protected]>,
|
---|
2241 | Nick Ing-Simmons <[email protected]>,
|
---|
2242 | Andreas J. KE<ouml>nig <[email protected]>,
|
---|
2243 | Markus Laker <[email protected]>,
|
---|
2244 | Andrew M. Langmead <[email protected]>,
|
---|
2245 | Larry Moore <[email protected]>,
|
---|
2246 | Paul Moore <[email protected]>,
|
---|
2247 | Chris Nandor <[email protected]>,
|
---|
2248 | Matthias Neeracher <[email protected]>,
|
---|
2249 | Philip Newton <[email protected]>,
|
---|
2250 | Gary Ng <[email protected]>,
|
---|
2251 | Tom Phoenix <[email protected]>,
|
---|
2252 | AndrE<eacute> Pirard <[email protected]>,
|
---|
2253 | Peter Prymmer <[email protected]>,
|
---|
2254 | Hugo van der Sanden <[email protected]>,
|
---|
2255 | Gurusamy Sarathy <[email protected]>,
|
---|
2256 | Paul J. Schinder <[email protected]>,
|
---|
2257 | Michael G Schwern <[email protected]>,
|
---|
2258 | Dan Sugalski <[email protected]>,
|
---|
2259 | Nathan Torkington <[email protected]>.
|
---|
2260 |
|
---|