| 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.9.2, 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: cpan-testers@perl.org |
| 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. emx@iaehv.nl, |
| 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, majordomo@perl.org |
| 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 | The value of C<$^O> on VOS is "VOS". To determine the architecture that |
| 1189 | you are running on without resorting to loading all of C<%Config> you |
| 1190 | can examine the content of the @INC array like so: |
| 1191 | |
| 1192 | if ($^O =~ /VOS/) { |
| 1193 | print "I'm on a Stratus box!\n"; |
| 1194 | } else { |
| 1195 | print "I'm not on a Stratus box!\n"; |
| 1196 | die; |
| 1197 | } |
| 1198 | |
| 1199 | Also see: |
| 1200 | |
| 1201 | =over 4 |
| 1202 | |
| 1203 | =item * |
| 1204 | |
| 1205 | F<README.vos> (installed as L<perlvos>) |
| 1206 | |
| 1207 | =item * |
| 1208 | |
| 1209 | The VOS mailing list. |
| 1210 | |
| 1211 | There is no specific mailing list for Perl on VOS. You can post |
| 1212 | comments to the comp.sys.stratus newsgroup, or subscribe to the general |
| 1213 | Stratus mailing list. Send a letter with "subscribe Info-Stratus" in |
| 1214 | the message body to majordomo@list.stratagy.com. |
| 1215 | |
| 1216 | =item * |
| 1217 | |
| 1218 | VOS Perl on the web at http://ftp.stratus.com/pub/vos/posix/posix.html |
| 1219 | |
| 1220 | =back |
| 1221 | |
| 1222 | =head2 EBCDIC Platforms |
| 1223 | |
| 1224 | Recent versions of Perl have been ported to platforms such as OS/400 on |
| 1225 | AS/400 minicomputers as well as OS/390, VM/ESA, and BS2000 for S/390 |
| 1226 | Mainframes. Such computers use EBCDIC character sets internally (usually |
| 1227 | Character Code Set ID 0037 for OS/400 and either 1047 or POSIX-BC for S/390 |
| 1228 | systems). On the mainframe perl currently works under the "Unix system |
| 1229 | services for OS/390" (formerly known as OpenEdition), VM/ESA OpenEdition, or |
| 1230 | the BS200 POSIX-BC system (BS2000 is supported in perl 5.6 and greater). |
| 1231 | See L<perlos390> for details. Note that for OS/400 there is also a port of |
| 1232 | Perl 5.8.1/5.9.0 or later to the PASE which is ASCII-based (as opposed to |
| 1233 | ILE which is EBCDIC-based), see L<perlos400>. |
| 1234 | |
| 1235 | As of R2.5 of USS for OS/390 and Version 2.3 of VM/ESA these Unix |
| 1236 | sub-systems do not support the C<#!> shebang trick for script invocation. |
| 1237 | Hence, on OS/390 and VM/ESA perl scripts can be executed with a header |
| 1238 | similar to the following simple script: |
| 1239 | |
| 1240 | : # use perl |
| 1241 | eval 'exec /usr/local/bin/perl -S $0 ${1+"$@"}' |
| 1242 | if 0; |
| 1243 | #!/usr/local/bin/perl # just a comment really |
| 1244 | |
| 1245 | print "Hello from perl!\n"; |
| 1246 | |
| 1247 | OS/390 will support the C<#!> shebang trick in release 2.8 and beyond. |
| 1248 | Calls to C<system> and backticks can use POSIX shell syntax on all |
| 1249 | S/390 systems. |
| 1250 | |
| 1251 | On the AS/400, if PERL5 is in your library list, you may need |
| 1252 | to wrap your perl scripts in a CL procedure to invoke them like so: |
| 1253 | |
| 1254 | BEGIN |
| 1255 | CALL PGM(PERL5/PERL) PARM('/QOpenSys/hello.pl') |
| 1256 | ENDPGM |
| 1257 | |
| 1258 | This will invoke the perl script F<hello.pl> in the root of the |
| 1259 | QOpenSys file system. On the AS/400 calls to C<system> or backticks |
| 1260 | must use CL syntax. |
| 1261 | |
| 1262 | On these platforms, bear in mind that the EBCDIC character set may have |
| 1263 | an effect on what happens with some perl functions (such as C<chr>, |
| 1264 | C<pack>, C<print>, C<printf>, C<ord>, C<sort>, C<sprintf>, C<unpack>), as |
| 1265 | well as bit-fiddling with ASCII constants using operators like C<^>, C<&> |
| 1266 | and C<|>, not to mention dealing with socket interfaces to ASCII computers |
| 1267 | (see L<"Newlines">). |
| 1268 | |
| 1269 | Fortunately, most web servers for the mainframe will correctly |
| 1270 | translate the C<\n> in the following statement to its ASCII equivalent |
| 1271 | (C<\r> is the same under both Unix and OS/390 & VM/ESA): |
| 1272 | |
| 1273 | print "Content-type: text/html\r\n\r\n"; |
| 1274 | |
| 1275 | The values of C<$^O> on some of these platforms includes: |
| 1276 | |
| 1277 | uname $^O $Config{'archname'} |
| 1278 | -------------------------------------------- |
| 1279 | OS/390 os390 os390 |
| 1280 | OS400 os400 os400 |
| 1281 | POSIX-BC posix-bc BS2000-posix-bc |
| 1282 | VM/ESA vmesa vmesa |
| 1283 | |
| 1284 | Some simple tricks for determining if you are running on an EBCDIC |
| 1285 | platform could include any of the following (perhaps all): |
| 1286 | |
| 1287 | if ("\t" eq "\05") { print "EBCDIC may be spoken here!\n"; } |
| 1288 | |
| 1289 | if (ord('A') == 193) { print "EBCDIC may be spoken here!\n"; } |
| 1290 | |
| 1291 | if (chr(169) eq 'z') { print "EBCDIC may be spoken here!\n"; } |
| 1292 | |
| 1293 | One thing you may not want to rely on is the EBCDIC encoding |
| 1294 | of punctuation characters since these may differ from code page to code |
| 1295 | page (and once your module or script is rumoured to work with EBCDIC, |
| 1296 | folks will want it to work with all EBCDIC character sets). |
| 1297 | |
| 1298 | Also see: |
| 1299 | |
| 1300 | =over 4 |
| 1301 | |
| 1302 | =item * |
| 1303 | |
| 1304 | L<perlos390>, F<README.os390>, F<perlbs2000>, F<README.vmesa>, |
| 1305 | L<perlebcdic>. |
| 1306 | |
| 1307 | =item * |
| 1308 | |
| 1309 | The perl-mvs@perl.org list is for discussion of porting issues as well as |
| 1310 | general usage issues for all EBCDIC Perls. Send a message body of |
| 1311 | "subscribe perl-mvs" to majordomo@perl.org. |
| 1312 | |
| 1313 | =item * |
| 1314 | |
| 1315 | AS/400 Perl information at |
| 1316 | http://as400.rochester.ibm.com/ |
| 1317 | as well as on CPAN in the F<ports/> directory. |
| 1318 | |
| 1319 | =back |
| 1320 | |
| 1321 | =head2 Acorn RISC OS |
| 1322 | |
| 1323 | Because Acorns use ASCII with newlines (C<\n>) in text files as C<\012> like |
| 1324 | Unix, and because Unix filename emulation is turned on by default, |
| 1325 | most simple scripts will probably work "out of the box". The native |
| 1326 | filesystem is modular, and individual filesystems are free to be |
| 1327 | case-sensitive or insensitive, and are usually case-preserving. Some |
| 1328 | native filesystems have name length limits, which file and directory |
| 1329 | names are silently truncated to fit. Scripts should be aware that the |
| 1330 | standard filesystem currently has a name length limit of B<10> |
| 1331 | characters, with up to 77 items in a directory, but other filesystems |
| 1332 | may not impose such limitations. |
| 1333 | |
| 1334 | Native filenames are of the form |
| 1335 | |
| 1336 | Filesystem#Special_Field::DiskName.$.Directory.Directory.File |
| 1337 | |
| 1338 | where |
| 1339 | |
| 1340 | Special_Field is not usually present, but may contain . and $ . |
| 1341 | Filesystem =~ m|[A-Za-z0-9_]| |
| 1342 | DsicName =~ m|[A-Za-z0-9_/]| |
| 1343 | $ represents the root directory |
| 1344 | . is the path separator |
| 1345 | @ is the current directory (per filesystem but machine global) |
| 1346 | ^ is the parent directory |
| 1347 | Directory and File =~ m|[^\0- "\.\$\%\&:\@\\^\|\177]+| |
| 1348 | |
| 1349 | The default filename translation is roughly C<tr|/.|./|;> |
| 1350 | |
| 1351 | Note that C<"ADFS::HardDisk.$.File" ne 'ADFS::HardDisk.$.File'> and that |
| 1352 | the second stage of C<$> interpolation in regular expressions will fall |
| 1353 | foul of the C<$.> if scripts are not careful. |
| 1354 | |
| 1355 | Logical paths specified by system variables containing comma-separated |
| 1356 | search lists are also allowed; hence C<System:Modules> is a valid |
| 1357 | filename, and the filesystem will prefix C<Modules> with each section of |
| 1358 | C<System$Path> until a name is made that points to an object on disk. |
| 1359 | Writing to a new file C<System:Modules> would be allowed only if |
| 1360 | C<System$Path> contains a single item list. The filesystem will also |
| 1361 | expand system variables in filenames if enclosed in angle brackets, so |
| 1362 | C<< <System$Dir>.Modules >> would look for the file |
| 1363 | S<C<$ENV{'System$Dir'} . 'Modules'>>. The obvious implication of this is |
| 1364 | that B<fully qualified filenames can start with C<< <> >>> and should |
| 1365 | be protected when C<open> is used for input. |
| 1366 | |
| 1367 | Because C<.> was in use as a directory separator and filenames could not |
| 1368 | be assumed to be unique after 10 characters, Acorn implemented the C |
| 1369 | compiler to strip the trailing C<.c> C<.h> C<.s> and C<.o> suffix from |
| 1370 | filenames specified in source code and store the respective files in |
| 1371 | subdirectories named after the suffix. Hence files are translated: |
| 1372 | |
| 1373 | foo.h h.foo |
| 1374 | C:foo.h C:h.foo (logical path variable) |
| 1375 | sys/os.h sys.h.os (C compiler groks Unix-speak) |
| 1376 | 10charname.c c.10charname |
| 1377 | 10charname.o o.10charname |
| 1378 | 11charname_.c c.11charname (assuming filesystem truncates at 10) |
| 1379 | |
| 1380 | The Unix emulation library's translation of filenames to native assumes |
| 1381 | that this sort of translation is required, and it allows a user-defined list |
| 1382 | of known suffixes that it will transpose in this fashion. This may |
| 1383 | seem transparent, but consider that with these rules C<foo/bar/baz.h> |
| 1384 | and C<foo/bar/h/baz> both map to C<foo.bar.h.baz>, and that C<readdir> and |
| 1385 | C<glob> cannot and do not attempt to emulate the reverse mapping. Other |
| 1386 | C<.>'s in filenames are translated to C</>. |
| 1387 | |
| 1388 | As implied above, the environment accessed through C<%ENV> is global, and |
| 1389 | the convention is that program specific environment variables are of the |
| 1390 | form C<Program$Name>. Each filesystem maintains a current directory, |
| 1391 | and the current filesystem's current directory is the B<global> current |
| 1392 | directory. Consequently, sociable programs don't change the current |
| 1393 | directory but rely on full pathnames, and programs (and Makefiles) cannot |
| 1394 | assume that they can spawn a child process which can change the current |
| 1395 | directory without affecting its parent (and everyone else for that |
| 1396 | matter). |
| 1397 | |
| 1398 | Because native operating system filehandles are global and are currently |
| 1399 | allocated down from 255, with 0 being a reserved value, the Unix emulation |
| 1400 | library emulates Unix filehandles. Consequently, you can't rely on |
| 1401 | passing C<STDIN>, C<STDOUT>, or C<STDERR> to your children. |
| 1402 | |
| 1403 | The desire of users to express filenames of the form |
| 1404 | C<< <Foo$Dir>.Bar >> on the command line unquoted causes problems, |
| 1405 | too: C<``> command output capture has to perform a guessing game. It |
| 1406 | assumes that a string C<< <[^<>]+\$[^<>]> >> is a |
| 1407 | reference to an environment variable, whereas anything else involving |
| 1408 | C<< < >> or C<< > >> is redirection, and generally manages to be 99% |
| 1409 | right. Of course, the problem remains that scripts cannot rely on any |
| 1410 | Unix tools being available, or that any tools found have Unix-like command |
| 1411 | line arguments. |
| 1412 | |
| 1413 | Extensions and XS are, in theory, buildable by anyone using free |
| 1414 | tools. In practice, many don't, as users of the Acorn platform are |
| 1415 | used to binary distributions. MakeMaker does run, but no available |
| 1416 | make currently copes with MakeMaker's makefiles; even if and when |
| 1417 | this should be fixed, the lack of a Unix-like shell will cause |
| 1418 | problems with makefile rules, especially lines of the form C<cd |
| 1419 | sdbm && make all>, and anything using quoting. |
| 1420 | |
| 1421 | "S<RISC OS>" is the proper name for the operating system, but the value |
| 1422 | in C<$^O> is "riscos" (because we don't like shouting). |
| 1423 | |
| 1424 | =head2 Other perls |
| 1425 | |
| 1426 | Perl has been ported to many platforms that do not fit into any of |
| 1427 | the categories listed above. Some, such as AmigaOS, Atari MiNT, |
| 1428 | BeOS, HP MPE/iX, QNX, Plan 9, and VOS, have been well-integrated |
| 1429 | into the standard Perl source code kit. You may need to see the |
| 1430 | F<ports/> directory on CPAN for information, and possibly binaries, |
| 1431 | for the likes of: aos, Atari ST, lynxos, riscos, Novell Netware, |
| 1432 | Tandem Guardian, I<etc.> (Yes, we know that some of these OSes may |
| 1433 | fall under the Unix category, but we are not a standards body.) |
| 1434 | |
| 1435 | Some approximate operating system names and their C<$^O> values |
| 1436 | in the "OTHER" category include: |
| 1437 | |
| 1438 | OS $^O $Config{'archname'} |
| 1439 | ------------------------------------------ |
| 1440 | Amiga DOS amigaos m68k-amigos |
| 1441 | BeOS beos |
| 1442 | MPE/iX mpeix PA-RISC1.1 |
| 1443 | |
| 1444 | See also: |
| 1445 | |
| 1446 | =over 4 |
| 1447 | |
| 1448 | =item * |
| 1449 | |
| 1450 | Amiga, F<README.amiga> (installed as L<perlamiga>). |
| 1451 | |
| 1452 | =item * |
| 1453 | |
| 1454 | Atari, F<README.mint> and Guido Flohr's web page |
| 1455 | http://stud.uni-sb.de/~gufl0000/ |
| 1456 | |
| 1457 | =item * |
| 1458 | |
| 1459 | Be OS, F<README.beos> |
| 1460 | |
| 1461 | =item * |
| 1462 | |
| 1463 | HP 300 MPE/iX, F<README.mpeix> and Mark Bixby's web page |
| 1464 | http://www.bixby.org/mark/perlix.html |
| 1465 | |
| 1466 | =item * |
| 1467 | |
| 1468 | A free perl5-based PERL.NLM for Novell Netware is available in |
| 1469 | precompiled binary and source code form from http://www.novell.com/ |
| 1470 | as well as from CPAN. |
| 1471 | |
| 1472 | =item * |
| 1473 | |
| 1474 | S<Plan 9>, F<README.plan9> |
| 1475 | |
| 1476 | =back |
| 1477 | |
| 1478 | =head1 FUNCTION IMPLEMENTATIONS |
| 1479 | |
| 1480 | Listed below are functions that are either completely unimplemented |
| 1481 | or else have been implemented differently on various platforms. |
| 1482 | Following each description will be, in parentheses, a list of |
| 1483 | platforms that the description applies to. |
| 1484 | |
| 1485 | The list may well be incomplete, or even wrong in some places. When |
| 1486 | in doubt, consult the platform-specific README files in the Perl |
| 1487 | source distribution, and any other documentation resources accompanying |
| 1488 | a given port. |
| 1489 | |
| 1490 | Be aware, moreover, that even among Unix-ish systems there are variations. |
| 1491 | |
| 1492 | For many functions, you can also query C<%Config>, exported by |
| 1493 | default from the Config module. For example, to check whether the |
| 1494 | platform has the C<lstat> call, check C<$Config{d_lstat}>. See |
| 1495 | L<Config> for a full description of available variables. |
| 1496 | |
| 1497 | =head2 Alphabetical Listing of Perl Functions |
| 1498 | |
| 1499 | =over 8 |
| 1500 | |
| 1501 | =item -X FILEHANDLE |
| 1502 | |
| 1503 | =item -X EXPR |
| 1504 | |
| 1505 | =item -X |
| 1506 | |
| 1507 | C<-r>, C<-w>, and C<-x> have a limited meaning only; directories |
| 1508 | and applications are executable, and there are no uid/gid |
| 1509 | considerations. C<-o> is not supported. (S<Mac OS>) |
| 1510 | |
| 1511 | C<-r>, C<-w>, C<-x>, and C<-o> tell whether the file is accessible, |
| 1512 | which may not reflect UIC-based file protections. (VMS) |
| 1513 | |
| 1514 | C<-s> returns the size of the data fork, not the total size of data fork |
| 1515 | plus resource fork. (S<Mac OS>). |
| 1516 | |
| 1517 | C<-s> by name on an open file will return the space reserved on disk, |
| 1518 | rather than the current extent. C<-s> on an open filehandle returns the |
| 1519 | current size. (S<RISC OS>) |
| 1520 | |
| 1521 | C<-R>, C<-W>, C<-X>, C<-O> are indistinguishable from C<-r>, C<-w>, |
| 1522 | C<-x>, C<-o>. (S<Mac OS>, Win32, VMS, S<RISC OS>) |
| 1523 | |
| 1524 | C<-b>, C<-c>, C<-k>, C<-g>, C<-p>, C<-u>, C<-A> are not implemented. |
| 1525 | (S<Mac OS>) |
| 1526 | |
| 1527 | C<-g>, C<-k>, C<-l>, C<-p>, C<-u>, C<-A> are not particularly meaningful. |
| 1528 | (Win32, VMS, S<RISC OS>) |
| 1529 | |
| 1530 | C<-d> is true if passed a device spec without an explicit directory. |
| 1531 | (VMS) |
| 1532 | |
| 1533 | C<-T> and C<-B> are implemented, but might misclassify Mac text files |
| 1534 | with foreign characters; this is the case will all platforms, but may |
| 1535 | affect S<Mac OS> often. (S<Mac OS>) |
| 1536 | |
| 1537 | C<-x> (or C<-X>) determine if a file ends in one of the executable |
| 1538 | suffixes. C<-S> is meaningless. (Win32) |
| 1539 | |
| 1540 | C<-x> (or C<-X>) determine if a file has an executable file type. |
| 1541 | (S<RISC OS>) |
| 1542 | |
| 1543 | =item binmode FILEHANDLE |
| 1544 | |
| 1545 | Meaningless. (S<Mac OS>, S<RISC OS>) |
| 1546 | |
| 1547 | Reopens file and restores pointer; if function fails, underlying |
| 1548 | filehandle may be closed, or pointer may be in a different position. |
| 1549 | (VMS) |
| 1550 | |
| 1551 | The value returned by C<tell> may be affected after the call, and |
| 1552 | the filehandle may be flushed. (Win32) |
| 1553 | |
| 1554 | =item chmod LIST |
| 1555 | |
| 1556 | Only limited meaning. Disabling/enabling write permission is mapped to |
| 1557 | locking/unlocking the file. (S<Mac OS>) |
| 1558 | |
| 1559 | Only good for changing "owner" read-write access, "group", and "other" |
| 1560 | bits are meaningless. (Win32) |
| 1561 | |
| 1562 | Only good for changing "owner" and "other" read-write access. (S<RISC OS>) |
| 1563 | |
| 1564 | Access permissions are mapped onto VOS access-control list changes. (VOS) |
| 1565 | |
| 1566 | The actual permissions set depend on the value of the C<CYGWIN> |
| 1567 | in the SYSTEM environment settings. (Cygwin) |
| 1568 | |
| 1569 | =item chown LIST |
| 1570 | |
| 1571 | Not implemented. (S<Mac OS>, Win32, S<Plan 9>, S<RISC OS>) |
| 1572 | |
| 1573 | Does nothing, but won't fail. (Win32) |
| 1574 | |
| 1575 | A little funky, because VOS's notion of ownership is a little funky (VOS). |
| 1576 | |
| 1577 | =item chroot FILENAME |
| 1578 | |
| 1579 | =item chroot |
| 1580 | |
| 1581 | Not implemented. (S<Mac OS>, Win32, VMS, S<Plan 9>, S<RISC OS>, VOS, VM/ESA) |
| 1582 | |
| 1583 | =item crypt PLAINTEXT,SALT |
| 1584 | |
| 1585 | May not be available if library or source was not provided when building |
| 1586 | perl. (Win32) |
| 1587 | |
| 1588 | =item dbmclose HASH |
| 1589 | |
| 1590 | Not implemented. (VMS, S<Plan 9>, VOS) |
| 1591 | |
| 1592 | =item dbmopen HASH,DBNAME,MODE |
| 1593 | |
| 1594 | Not implemented. (VMS, S<Plan 9>, VOS) |
| 1595 | |
| 1596 | =item dump LABEL |
| 1597 | |
| 1598 | Not useful. (S<Mac OS>, S<RISC OS>) |
| 1599 | |
| 1600 | Not implemented. (Win32) |
| 1601 | |
| 1602 | Invokes VMS debugger. (VMS) |
| 1603 | |
| 1604 | =item exec LIST |
| 1605 | |
| 1606 | Not implemented. (S<Mac OS>) |
| 1607 | |
| 1608 | Implemented via Spawn. (VM/ESA) |
| 1609 | |
| 1610 | Does not automatically flush output handles on some platforms. |
| 1611 | (SunOS, Solaris, HP-UX) |
| 1612 | |
| 1613 | =item exit EXPR |
| 1614 | |
| 1615 | =item exit |
| 1616 | |
| 1617 | Emulates UNIX exit() (which considers C<exit 1> to indicate an error) by |
| 1618 | mapping the C<1> to SS$_ABORT (C<44>). This behavior may be overridden |
| 1619 | with the pragma C<use vmsish 'exit'>. As with the CRTL's exit() |
| 1620 | function, C<exit 0> is also mapped to an exit status of SS$_NORMAL |
| 1621 | (C<1>); this mapping cannot be overridden. Any other argument to exit() |
| 1622 | is used directly as Perl's exit status. (VMS) |
| 1623 | |
| 1624 | =item fcntl FILEHANDLE,FUNCTION,SCALAR |
| 1625 | |
| 1626 | Not implemented. (Win32, VMS) |
| 1627 | |
| 1628 | =item flock FILEHANDLE,OPERATION |
| 1629 | |
| 1630 | Not implemented (S<Mac OS>, VMS, S<RISC OS>, VOS). |
| 1631 | |
| 1632 | Available only on Windows NT (not on Windows 95). (Win32) |
| 1633 | |
| 1634 | =item fork |
| 1635 | |
| 1636 | Not implemented. (S<Mac OS>, AmigaOS, S<RISC OS>, VM/ESA, VMS) |
| 1637 | |
| 1638 | Emulated using multiple interpreters. See L<perlfork>. (Win32) |
| 1639 | |
| 1640 | Does not automatically flush output handles on some platforms. |
| 1641 | (SunOS, Solaris, HP-UX) |
| 1642 | |
| 1643 | =item getlogin |
| 1644 | |
| 1645 | Not implemented. (S<Mac OS>, S<RISC OS>) |
| 1646 | |
| 1647 | =item getpgrp PID |
| 1648 | |
| 1649 | Not implemented. (S<Mac OS>, Win32, VMS, S<RISC OS>) |
| 1650 | |
| 1651 | =item getppid |
| 1652 | |
| 1653 | Not implemented. (S<Mac OS>, Win32, S<RISC OS>) |
| 1654 | |
| 1655 | =item getpriority WHICH,WHO |
| 1656 | |
| 1657 | Not implemented. (S<Mac OS>, Win32, VMS, S<RISC OS>, VOS, VM/ESA) |
| 1658 | |
| 1659 | =item getpwnam NAME |
| 1660 | |
| 1661 | Not implemented. (S<Mac OS>, Win32) |
| 1662 | |
| 1663 | Not useful. (S<RISC OS>) |
| 1664 | |
| 1665 | =item getgrnam NAME |
| 1666 | |
| 1667 | Not implemented. (S<Mac OS>, Win32, VMS, S<RISC OS>) |
| 1668 | |
| 1669 | =item getnetbyname NAME |
| 1670 | |
| 1671 | Not implemented. (S<Mac OS>, Win32, S<Plan 9>) |
| 1672 | |
| 1673 | =item getpwuid UID |
| 1674 | |
| 1675 | Not implemented. (S<Mac OS>, Win32) |
| 1676 | |
| 1677 | Not useful. (S<RISC OS>) |
| 1678 | |
| 1679 | =item getgrgid GID |
| 1680 | |
| 1681 | Not implemented. (S<Mac OS>, Win32, VMS, S<RISC OS>) |
| 1682 | |
| 1683 | =item getnetbyaddr ADDR,ADDRTYPE |
| 1684 | |
| 1685 | Not implemented. (S<Mac OS>, Win32, S<Plan 9>) |
| 1686 | |
| 1687 | =item getprotobynumber NUMBER |
| 1688 | |
| 1689 | Not implemented. (S<Mac OS>) |
| 1690 | |
| 1691 | =item getservbyport PORT,PROTO |
| 1692 | |
| 1693 | Not implemented. (S<Mac OS>) |
| 1694 | |
| 1695 | =item getpwent |
| 1696 | |
| 1697 | Not implemented. (S<Mac OS>, Win32, VM/ESA) |
| 1698 | |
| 1699 | =item getgrent |
| 1700 | |
| 1701 | Not implemented. (S<Mac OS>, Win32, VMS, VM/ESA) |
| 1702 | |
| 1703 | =item gethostbyname |
| 1704 | |
| 1705 | C<gethostbyname('localhost')> does not work everywhere: you may have |
| 1706 | to use C<gethostbyname('127.0.0.1')>. (S<Mac OS>, S<Irix 5>) |
| 1707 | |
| 1708 | =item gethostent |
| 1709 | |
| 1710 | Not implemented. (S<Mac OS>, Win32) |
| 1711 | |
| 1712 | =item getnetent |
| 1713 | |
| 1714 | Not implemented. (S<Mac OS>, Win32, S<Plan 9>) |
| 1715 | |
| 1716 | =item getprotoent |
| 1717 | |
| 1718 | Not implemented. (S<Mac OS>, Win32, S<Plan 9>) |
| 1719 | |
| 1720 | =item getservent |
| 1721 | |
| 1722 | Not implemented. (Win32, S<Plan 9>) |
| 1723 | |
| 1724 | =item sethostent STAYOPEN |
| 1725 | |
| 1726 | Not implemented. (S<Mac OS>, Win32, S<Plan 9>, S<RISC OS>) |
| 1727 | |
| 1728 | =item setnetent STAYOPEN |
| 1729 | |
| 1730 | Not implemented. (S<Mac OS>, Win32, S<Plan 9>, S<RISC OS>) |
| 1731 | |
| 1732 | =item setprotoent STAYOPEN |
| 1733 | |
| 1734 | Not implemented. (S<Mac OS>, Win32, S<Plan 9>, S<RISC OS>) |
| 1735 | |
| 1736 | =item setservent STAYOPEN |
| 1737 | |
| 1738 | Not implemented. (S<Plan 9>, Win32, S<RISC OS>) |
| 1739 | |
| 1740 | =item endpwent |
| 1741 | |
| 1742 | Not implemented. (S<Mac OS>, MPE/iX, VM/ESA, Win32) |
| 1743 | |
| 1744 | =item endgrent |
| 1745 | |
| 1746 | Not implemented. (S<Mac OS>, MPE/iX, S<RISC OS>, VM/ESA, VMS, Win32) |
| 1747 | |
| 1748 | =item endhostent |
| 1749 | |
| 1750 | Not implemented. (S<Mac OS>, Win32) |
| 1751 | |
| 1752 | =item endnetent |
| 1753 | |
| 1754 | Not implemented. (S<Mac OS>, Win32, S<Plan 9>) |
| 1755 | |
| 1756 | =item endprotoent |
| 1757 | |
| 1758 | Not implemented. (S<Mac OS>, Win32, S<Plan 9>) |
| 1759 | |
| 1760 | =item endservent |
| 1761 | |
| 1762 | Not implemented. (S<Plan 9>, Win32) |
| 1763 | |
| 1764 | =item getsockopt SOCKET,LEVEL,OPTNAME |
| 1765 | |
| 1766 | Not implemented. (S<Plan 9>) |
| 1767 | |
| 1768 | =item glob EXPR |
| 1769 | |
| 1770 | =item glob |
| 1771 | |
| 1772 | This operator is implemented via the File::Glob extension on most |
| 1773 | platforms. See L<File::Glob> for portability information. |
| 1774 | |
| 1775 | =item ioctl FILEHANDLE,FUNCTION,SCALAR |
| 1776 | |
| 1777 | Not implemented. (VMS) |
| 1778 | |
| 1779 | Available only for socket handles, and it does what the ioctlsocket() call |
| 1780 | in the Winsock API does. (Win32) |
| 1781 | |
| 1782 | Available only for socket handles. (S<RISC OS>) |
| 1783 | |
| 1784 | =item kill SIGNAL, LIST |
| 1785 | |
| 1786 | C<kill(0, LIST)> is implemented for the sake of taint checking; |
| 1787 | use with other signals is unimplemented. (S<Mac OS>) |
| 1788 | |
| 1789 | Not implemented, hence not useful for taint checking. (S<RISC OS>) |
| 1790 | |
| 1791 | C<kill()> doesn't have the semantics of C<raise()>, i.e. it doesn't send |
| 1792 | a signal to the identified process like it does on Unix platforms. |
| 1793 | Instead C<kill($sig, $pid)> terminates the process identified by $pid, |
| 1794 | and makes it exit immediately with exit status $sig. As in Unix, if |
| 1795 | $sig is 0 and the specified process exists, it returns true without |
| 1796 | actually terminating it. (Win32) |
| 1797 | |
| 1798 | =item link OLDFILE,NEWFILE |
| 1799 | |
| 1800 | Not implemented. (S<Mac OS>, MPE/iX, VMS, S<RISC OS>) |
| 1801 | |
| 1802 | Link count not updated because hard links are not quite that hard |
| 1803 | (They are sort of half-way between hard and soft links). (AmigaOS) |
| 1804 | |
| 1805 | Hard links are implemented on Win32 (Windows NT and Windows 2000) |
| 1806 | under NTFS only. |
| 1807 | |
| 1808 | =item lstat FILEHANDLE |
| 1809 | |
| 1810 | =item lstat EXPR |
| 1811 | |
| 1812 | =item lstat |
| 1813 | |
| 1814 | Not implemented. (VMS, S<RISC OS>) |
| 1815 | |
| 1816 | Return values (especially for device and inode) may be bogus. (Win32) |
| 1817 | |
| 1818 | =item msgctl ID,CMD,ARG |
| 1819 | |
| 1820 | =item msgget KEY,FLAGS |
| 1821 | |
| 1822 | =item msgsnd ID,MSG,FLAGS |
| 1823 | |
| 1824 | =item msgrcv ID,VAR,SIZE,TYPE,FLAGS |
| 1825 | |
| 1826 | Not implemented. (S<Mac OS>, Win32, VMS, S<Plan 9>, S<RISC OS>, VOS) |
| 1827 | |
| 1828 | =item open FILEHANDLE,EXPR |
| 1829 | |
| 1830 | =item open FILEHANDLE |
| 1831 | |
| 1832 | The C<|> variants are supported only if ToolServer is installed. |
| 1833 | (S<Mac OS>) |
| 1834 | |
| 1835 | open to C<|-> and C<-|> are unsupported. (S<Mac OS>, Win32, S<RISC OS>) |
| 1836 | |
| 1837 | Opening a process does not automatically flush output handles on some |
| 1838 | platforms. (SunOS, Solaris, HP-UX) |
| 1839 | |
| 1840 | =item pipe READHANDLE,WRITEHANDLE |
| 1841 | |
| 1842 | Very limited functionality. (MiNT) |
| 1843 | |
| 1844 | =item readlink EXPR |
| 1845 | |
| 1846 | =item readlink |
| 1847 | |
| 1848 | Not implemented. (Win32, VMS, S<RISC OS>) |
| 1849 | |
| 1850 | =item rename OLDNAME,NEWNAME |
| 1851 | |
| 1852 | Can't move directories between directories on different logical volumes. (Win32) |
| 1853 | |
| 1854 | =item select RBITS,WBITS,EBITS,TIMEOUT |
| 1855 | |
| 1856 | Only implemented on sockets. (Win32, VMS) |
| 1857 | |
| 1858 | Only reliable on sockets. (S<RISC OS>) |
| 1859 | |
| 1860 | Note that the C<select FILEHANDLE> form is generally portable. |
| 1861 | |
| 1862 | =item semctl ID,SEMNUM,CMD,ARG |
| 1863 | |
| 1864 | =item semget KEY,NSEMS,FLAGS |
| 1865 | |
| 1866 | =item semop KEY,OPSTRING |
| 1867 | |
| 1868 | Not implemented. (S<Mac OS>, Win32, VMS, S<RISC OS>, VOS) |
| 1869 | |
| 1870 | =item setgrent |
| 1871 | |
| 1872 | Not implemented. (S<Mac OS>, MPE/iX, VMS, Win32, S<RISC OS>, VOS) |
| 1873 | |
| 1874 | =item setpgrp PID,PGRP |
| 1875 | |
| 1876 | Not implemented. (S<Mac OS>, Win32, VMS, S<RISC OS>, VOS) |
| 1877 | |
| 1878 | =item setpriority WHICH,WHO,PRIORITY |
| 1879 | |
| 1880 | Not implemented. (S<Mac OS>, Win32, VMS, S<RISC OS>, VOS) |
| 1881 | |
| 1882 | =item setpwent |
| 1883 | |
| 1884 | Not implemented. (S<Mac OS>, MPE/iX, Win32, S<RISC OS>, VOS) |
| 1885 | |
| 1886 | =item setsockopt SOCKET,LEVEL,OPTNAME,OPTVAL |
| 1887 | |
| 1888 | Not implemented. (S<Plan 9>) |
| 1889 | |
| 1890 | =item shmctl ID,CMD,ARG |
| 1891 | |
| 1892 | =item shmget KEY,SIZE,FLAGS |
| 1893 | |
| 1894 | =item shmread ID,VAR,POS,SIZE |
| 1895 | |
| 1896 | =item shmwrite ID,STRING,POS,SIZE |
| 1897 | |
| 1898 | Not implemented. (S<Mac OS>, Win32, VMS, S<RISC OS>, VOS) |
| 1899 | |
| 1900 | =item sockatmark SOCKET |
| 1901 | |
| 1902 | A relatively recent addition to socket functions, may not |
| 1903 | be implemented even in UNIX platforms. |
| 1904 | |
| 1905 | =item socketpair SOCKET1,SOCKET2,DOMAIN,TYPE,PROTOCOL |
| 1906 | |
| 1907 | Not implemented. (Win32, VMS, S<RISC OS>, VOS, VM/ESA) |
| 1908 | |
| 1909 | =item stat FILEHANDLE |
| 1910 | |
| 1911 | =item stat EXPR |
| 1912 | |
| 1913 | =item stat |
| 1914 | |
| 1915 | Platforms that do not have rdev, blksize, or blocks will return these |
| 1916 | as '', so numeric comparison or manipulation of these fields may cause |
| 1917 | 'not numeric' warnings. |
| 1918 | |
| 1919 | mtime and atime are the same thing, and ctime is creation time instead of |
| 1920 | inode change time. (S<Mac OS>). |
| 1921 | |
| 1922 | ctime not supported on UFS (S<Mac OS X>). |
| 1923 | |
| 1924 | ctime is creation time instead of inode change time (Win32). |
| 1925 | |
| 1926 | device and inode are not meaningful. (Win32) |
| 1927 | |
| 1928 | device and inode are not necessarily reliable. (VMS) |
| 1929 | |
| 1930 | mtime, atime and ctime all return the last modification time. Device and |
| 1931 | inode are not necessarily reliable. (S<RISC OS>) |
| 1932 | |
| 1933 | dev, rdev, blksize, and blocks are not available. inode is not |
| 1934 | meaningful and will differ between stat calls on the same file. (os2) |
| 1935 | |
| 1936 | some versions of cygwin when doing a stat("foo") and if not finding it |
| 1937 | may then attempt to stat("foo.exe") (Cygwin) |
| 1938 | |
| 1939 | =item symlink OLDFILE,NEWFILE |
| 1940 | |
| 1941 | Not implemented. (Win32, VMS, S<RISC OS>) |
| 1942 | |
| 1943 | =item syscall LIST |
| 1944 | |
| 1945 | Not implemented. (S<Mac OS>, Win32, VMS, S<RISC OS>, VOS, VM/ESA) |
| 1946 | |
| 1947 | =item sysopen FILEHANDLE,FILENAME,MODE,PERMS |
| 1948 | |
| 1949 | The traditional "0", "1", and "2" MODEs are implemented with different |
| 1950 | numeric values on some systems. The flags exported by C<Fcntl> |
| 1951 | (O_RDONLY, O_WRONLY, O_RDWR) should work everywhere though. (S<Mac |
| 1952 | OS>, OS/390, VM/ESA) |
| 1953 | |
| 1954 | =item system LIST |
| 1955 | |
| 1956 | In general, do not assume the UNIX/POSIX semantics that you can shift |
| 1957 | C<$?> right by eight to get the exit value, or that C<$? & 127> |
| 1958 | would give you the number of the signal that terminated the program, |
| 1959 | or that C<$? & 128> would test true if the program was terminated by a |
| 1960 | coredump. Instead, use the POSIX W*() interfaces: for example, use |
| 1961 | WIFEXITED($?) and WEXITVALUE($?) to test for a normal exit and the exit |
| 1962 | value, WIFSIGNALED($?) and WTERMSIG($?) for a signal exit and the |
| 1963 | signal. Core dumping is not a portable concept, so there's no portable |
| 1964 | way to test for that. |
| 1965 | |
| 1966 | Only implemented if ToolServer is installed. (S<Mac OS>) |
| 1967 | |
| 1968 | As an optimization, may not call the command shell specified in |
| 1969 | C<$ENV{PERL5SHELL}>. C<system(1, @args)> spawns an external |
| 1970 | process and immediately returns its process designator, without |
| 1971 | waiting for it to terminate. Return value may be used subsequently |
| 1972 | in C<wait> or C<waitpid>. Failure to spawn() a subprocess is indicated |
| 1973 | by setting $? to "255 << 8". C<$?> is set in a way compatible with |
| 1974 | Unix (i.e. the exitstatus of the subprocess is obtained by "$? >> 8", |
| 1975 | as described in the documentation). (Win32) |
| 1976 | |
| 1977 | There is no shell to process metacharacters, and the native standard is |
| 1978 | to pass a command line terminated by "\n" "\r" or "\0" to the spawned |
| 1979 | program. Redirection such as C<< > foo >> is performed (if at all) by |
| 1980 | the run time library of the spawned program. C<system> I<list> will call |
| 1981 | the Unix emulation library's C<exec> emulation, which attempts to provide |
| 1982 | emulation of the stdin, stdout, stderr in force in the parent, providing |
| 1983 | the child program uses a compatible version of the emulation library. |
| 1984 | I<scalar> will call the native command line direct and no such emulation |
| 1985 | of a child Unix program will exists. Mileage B<will> vary. (S<RISC OS>) |
| 1986 | |
| 1987 | Far from being POSIX compliant. Because there may be no underlying |
| 1988 | /bin/sh tries to work around the problem by forking and execing the |
| 1989 | first token in its argument string. Handles basic redirection |
| 1990 | ("<" or ">") on its own behalf. (MiNT) |
| 1991 | |
| 1992 | Does not automatically flush output handles on some platforms. |
| 1993 | (SunOS, Solaris, HP-UX) |
| 1994 | |
| 1995 | The return value is POSIX-like (shifted up by 8 bits), which only allows |
| 1996 | room for a made-up value derived from the severity bits of the native |
| 1997 | 32-bit condition code (unless overridden by C<use vmsish 'status'>). |
| 1998 | For more details see L<perlvms/$?>. (VMS) |
| 1999 | |
| 2000 | =item times |
| 2001 | |
| 2002 | Only the first entry returned is nonzero. (S<Mac OS>) |
| 2003 | |
| 2004 | "cumulative" times will be bogus. On anything other than Windows NT |
| 2005 | or Windows 2000, "system" time will be bogus, and "user" time is |
| 2006 | actually the time returned by the clock() function in the C runtime |
| 2007 | library. (Win32) |
| 2008 | |
| 2009 | Not useful. (S<RISC OS>) |
| 2010 | |
| 2011 | =item truncate FILEHANDLE,LENGTH |
| 2012 | |
| 2013 | =item truncate EXPR,LENGTH |
| 2014 | |
| 2015 | Not implemented. (Older versions of VMS) |
| 2016 | |
| 2017 | Truncation to same-or-shorter lengths only. (VOS) |
| 2018 | |
| 2019 | If a FILEHANDLE is supplied, it must be writable and opened in append |
| 2020 | mode (i.e., use C<<< open(FH, '>>filename') >>> |
| 2021 | or C<sysopen(FH,...,O_APPEND|O_RDWR)>. If a filename is supplied, it |
| 2022 | should not be held open elsewhere. (Win32) |
| 2023 | |
| 2024 | =item umask EXPR |
| 2025 | |
| 2026 | =item umask |
| 2027 | |
| 2028 | Returns undef where unavailable, as of version 5.005. |
| 2029 | |
| 2030 | C<umask> works but the correct permissions are set only when the file |
| 2031 | is finally closed. (AmigaOS) |
| 2032 | |
| 2033 | =item utime LIST |
| 2034 | |
| 2035 | Only the modification time is updated. (S<BeOS>, S<Mac OS>, VMS, S<RISC OS>) |
| 2036 | |
| 2037 | May not behave as expected. Behavior depends on the C runtime |
| 2038 | library's implementation of utime(), and the filesystem being |
| 2039 | used. The FAT filesystem typically does not support an "access |
| 2040 | time" field, and it may limit timestamps to a granularity of |
| 2041 | two seconds. (Win32) |
| 2042 | |
| 2043 | =item wait |
| 2044 | |
| 2045 | =item waitpid PID,FLAGS |
| 2046 | |
| 2047 | Not implemented. (S<Mac OS>) |
| 2048 | |
| 2049 | Can only be applied to process handles returned for processes spawned |
| 2050 | using C<system(1, ...)> or pseudo processes created with C<fork()>. (Win32) |
| 2051 | |
| 2052 | Not useful. (S<RISC OS>) |
| 2053 | |
| 2054 | =back |
| 2055 | |
| 2056 | =head1 CHANGES |
| 2057 | |
| 2058 | =over 4 |
| 2059 | |
| 2060 | =item v1.49, 12 August 2002 |
| 2061 | |
| 2062 | Updates for VOS from Paul Green. |
| 2063 | |
| 2064 | =item v1.48, 02 February 2001 |
| 2065 | |
| 2066 | Various updates from perl5-porters over the past year, supported |
| 2067 | platforms update from Jarkko Hietaniemi. |
| 2068 | |
| 2069 | =item v1.47, 22 March 2000 |
| 2070 | |
| 2071 | Various cleanups from Tom Christiansen, including migration of |
| 2072 | long platform listings from L<perl>. |
| 2073 | |
| 2074 | =item v1.46, 12 February 2000 |
| 2075 | |
| 2076 | Updates for VOS and MPE/iX. (Peter Prymmer) Other small changes. |
| 2077 | |
| 2078 | =item v1.45, 20 December 1999 |
| 2079 | |
| 2080 | Small changes from 5.005_63 distribution, more changes to EBCDIC info. |
| 2081 | |
| 2082 | =item v1.44, 19 July 1999 |
| 2083 | |
| 2084 | A bunch of updates from Peter Prymmer for C<$^O> values, |
| 2085 | endianness, File::Spec, VMS, BS2000, OS/400. |
| 2086 | |
| 2087 | =item v1.43, 24 May 1999 |
| 2088 | |
| 2089 | Added a lot of cleaning up from Tom Christiansen. |
| 2090 | |
| 2091 | =item v1.42, 22 May 1999 |
| 2092 | |
| 2093 | Added notes about tests, sprintf/printf, and epoch offsets. |
| 2094 | |
| 2095 | =item v1.41, 19 May 1999 |
| 2096 | |
| 2097 | Lots more little changes to formatting and content. |
| 2098 | |
| 2099 | Added a bunch of C<$^O> and related values |
| 2100 | for various platforms; fixed mail and web addresses, and added |
| 2101 | and changed miscellaneous notes. (Peter Prymmer) |
| 2102 | |
| 2103 | =item v1.40, 11 April 1999 |
| 2104 | |
| 2105 | Miscellaneous changes. |
| 2106 | |
| 2107 | =item v1.39, 11 February 1999 |
| 2108 | |
| 2109 | Changes from Jarkko and EMX URL fixes Michael Schwern. Additional |
| 2110 | note about newlines added. |
| 2111 | |
| 2112 | =item v1.38, 31 December 1998 |
| 2113 | |
| 2114 | More changes from Jarkko. |
| 2115 | |
| 2116 | =item v1.37, 19 December 1998 |
| 2117 | |
| 2118 | More minor changes. Merge two separate version 1.35 documents. |
| 2119 | |
| 2120 | =item v1.36, 9 September 1998 |
| 2121 | |
| 2122 | Updated for Stratus VOS. Also known as version 1.35. |
| 2123 | |
| 2124 | =item v1.35, 13 August 1998 |
| 2125 | |
| 2126 | Integrate more minor changes, plus addition of new sections under |
| 2127 | L<"ISSUES">: L<"Numbers endianness and Width">, |
| 2128 | L<"Character sets and character encoding">, |
| 2129 | L<"Internationalisation">. |
| 2130 | |
| 2131 | =item v1.33, 06 August 1998 |
| 2132 | |
| 2133 | Integrate more minor changes. |
| 2134 | |
| 2135 | =item v1.32, 05 August 1998 |
| 2136 | |
| 2137 | Integrate more minor changes. |
| 2138 | |
| 2139 | =item v1.30, 03 August 1998 |
| 2140 | |
| 2141 | Major update for RISC OS, other minor changes. |
| 2142 | |
| 2143 | =item v1.23, 10 July 1998 |
| 2144 | |
| 2145 | First public release with perl5.005. |
| 2146 | |
| 2147 | =back |
| 2148 | |
| 2149 | =head1 Supported Platforms |
| 2150 | |
| 2151 | As of July 2002 (the Perl release 5.8.0), the following platforms are |
| 2152 | able to build Perl from the standard source code distribution |
| 2153 | available at http://www.cpan.org/src/index.html |
| 2154 | |
| 2155 | AIX |
| 2156 | BeOS |
| 2157 | BSD/OS (BSDi) |
| 2158 | Cygwin |
| 2159 | DG/UX |
| 2160 | DOS DJGPP 1) |
| 2161 | DYNIX/ptx |
| 2162 | EPOC R5 |
| 2163 | FreeBSD |
| 2164 | HI-UXMPP (Hitachi) (5.8.0 worked but we didn't know it) |
| 2165 | HP-UX |
| 2166 | IRIX |
| 2167 | Linux |
| 2168 | Mac OS Classic |
| 2169 | Mac OS X (Darwin) |
| 2170 | MPE/iX |
| 2171 | NetBSD |
| 2172 | NetWare |
| 2173 | NonStop-UX |
| 2174 | ReliantUNIX (formerly SINIX) |
| 2175 | OpenBSD |
| 2176 | OpenVMS (formerly VMS) |
| 2177 | Open UNIX (Unixware) (since Perl 5.8.1/5.9.0) |
| 2178 | OS/2 |
| 2179 | OS/400 (using the PASE) (since Perl 5.8.1/5.9.0) |
| 2180 | PowerUX |
| 2181 | POSIX-BC (formerly BS2000) |
| 2182 | QNX |
| 2183 | Solaris |
| 2184 | SunOS 4 |
| 2185 | SUPER-UX (NEC) |
| 2186 | Tru64 UNIX (formerly DEC OSF/1, Digital UNIX) |
| 2187 | UNICOS |
| 2188 | UNICOS/mk |
| 2189 | UTS |
| 2190 | VOS |
| 2191 | Win95/98/ME/2K/XP 2) |
| 2192 | WinCE |
| 2193 | z/OS (formerly OS/390) |
| 2194 | VM/ESA |
| 2195 | |
| 2196 | 1) in DOS mode either the DOS or OS/2 ports can be used |
| 2197 | 2) compilers: Borland, MinGW (GCC), VC6 |
| 2198 | |
| 2199 | The following platforms worked with the previous releases (5.6 and |
| 2200 | 5.7), but we did not manage either to fix or to test these in time |
| 2201 | for the 5.8.0 release. There is a very good chance that many of these |
| 2202 | will work fine with the 5.8.0. |
| 2203 | |
| 2204 | BSD/OS |
| 2205 | DomainOS |
| 2206 | Hurd |
| 2207 | LynxOS |
| 2208 | MachTen |
| 2209 | PowerMAX |
| 2210 | SCO SV |
| 2211 | SVR4 |
| 2212 | Unixware |
| 2213 | Windows 3.1 |
| 2214 | |
| 2215 | Known to be broken for 5.8.0 (but 5.6.1 and 5.7.2 can be used): |
| 2216 | |
| 2217 | AmigaOS |
| 2218 | |
| 2219 | The following platforms have been known to build Perl from source in |
| 2220 | the past (5.005_03 and earlier), but we haven't been able to verify |
| 2221 | their status for the current release, either because the |
| 2222 | hardware/software platforms are rare or because we don't have an |
| 2223 | active champion on these platforms--or both. They used to work, |
| 2224 | though, so go ahead and try compiling them, and let perlbug@perl.org |
| 2225 | of any trouble. |
| 2226 | |
| 2227 | 3b1 |
| 2228 | A/UX |
| 2229 | ConvexOS |
| 2230 | CX/UX |
| 2231 | DC/OSx |
| 2232 | DDE SMES |
| 2233 | DOS EMX |
| 2234 | Dynix |
| 2235 | EP/IX |
| 2236 | ESIX |
| 2237 | FPS |
| 2238 | GENIX |
| 2239 | Greenhills |
| 2240 | ISC |
| 2241 | MachTen 68k |
| 2242 | MiNT |
| 2243 | MPC |
| 2244 | NEWS-OS |
| 2245 | NextSTEP |
| 2246 | OpenSTEP |
| 2247 | Opus |
| 2248 | Plan 9 |
| 2249 | RISC/os |
| 2250 | SCO ODT/OSR |
| 2251 | Stellar |
| 2252 | SVR2 |
| 2253 | TI1500 |
| 2254 | TitanOS |
| 2255 | Ultrix |
| 2256 | Unisys Dynix |
| 2257 | |
| 2258 | The following platforms have their own source code distributions and |
| 2259 | binaries available via http://www.cpan.org/ports/ |
| 2260 | |
| 2261 | Perl release |
| 2262 | |
| 2263 | OS/400 (ILE) 5.005_02 |
| 2264 | Tandem Guardian 5.004 |
| 2265 | |
| 2266 | The following platforms have only binaries available via |
| 2267 | http://www.cpan.org/ports/index.html : |
| 2268 | |
| 2269 | Perl release |
| 2270 | |
| 2271 | Acorn RISCOS 5.005_02 |
| 2272 | AOS 5.002 |
| 2273 | LynxOS 5.004_02 |
| 2274 | |
| 2275 | Although we do suggest that you always build your own Perl from |
| 2276 | the source code, both for maximal configurability and for security, |
| 2277 | in case you are in a hurry you can check |
| 2278 | http://www.cpan.org/ports/index.html for binary distributions. |
| 2279 | |
| 2280 | =head1 SEE ALSO |
| 2281 | |
| 2282 | L<perlaix>, L<perlamiga>, L<perlapollo>, L<perlbeos>, L<perlbs2000>, |
| 2283 | L<perlce>, L<perlcygwin>, L<perldgux>, L<perldos>, L<perlepoc>, |
| 2284 | L<perlebcdic>, L<perlfreebsd>, L<perlhurd>, L<perlhpux>, L<perlirix>, |
| 2285 | L<perlmachten>, L<perlmacos>, L<perlmacosx>, L<perlmint>, L<perlmpeix>, |
| 2286 | L<perlnetware>, L<perlos2>, L<perlos390>, L<perlos400>, |
| 2287 | L<perlplan9>, L<perlqnx>, L<perlsolaris>, L<perltru64>, |
| 2288 | L<perlunicode>, L<perlvmesa>, L<perlvms>, L<perlvos>, |
| 2289 | L<perlwin32>, and L<Win32>. |
| 2290 | |
| 2291 | =head1 AUTHORS / CONTRIBUTORS |
| 2292 | |
| 2293 | Abigail <abigail@foad.org>, |
| 2294 | Charles Bailey <bailey@newman.upenn.edu>, |
| 2295 | Graham Barr <gbarr@pobox.com>, |
| 2296 | Tom Christiansen <tchrist@perl.com>, |
| 2297 | Nicholas Clark <nick@ccl4.org>, |
| 2298 | Thomas Dorner <Thomas.Dorner@start.de>, |
| 2299 | Andy Dougherty <doughera@lafayette.edu>, |
| 2300 | Dominic Dunlop <domo@computer.org>, |
| 2301 | Neale Ferguson <neale@vma.tabnsw.com.au>, |
| 2302 | David J. Fiander <davidf@mks.com>, |
| 2303 | Paul Green <Paul.Green@stratus.com>, |
| 2304 | M.J.T. Guy <mjtg@cam.ac.uk>, |
| 2305 | Jarkko Hietaniemi <jhi@iki.fi>, |
| 2306 | Luther Huffman <lutherh@stratcom.com>, |
| 2307 | Nick Ing-Simmons <nick@ing-simmons.net>, |
| 2308 | Andreas J. KE<ouml>nig <a.koenig@mind.de>, |
| 2309 | Markus Laker <mlaker@contax.co.uk>, |
| 2310 | Andrew M. Langmead <aml@world.std.com>, |
| 2311 | Larry Moore <ljmoore@freespace.net>, |
| 2312 | Paul Moore <Paul.Moore@uk.origin-it.com>, |
| 2313 | Chris Nandor <pudge@pobox.com>, |
| 2314 | Matthias Neeracher <neeracher@mac.com>, |
| 2315 | Philip Newton <pne@cpan.org>, |
| 2316 | Gary Ng <71564.1743@CompuServe.COM>, |
| 2317 | Tom Phoenix <rootbeer@teleport.com>, |
| 2318 | AndrE<eacute> Pirard <A.Pirard@ulg.ac.be>, |
| 2319 | Peter Prymmer <pvhp@forte.com>, |
| 2320 | Hugo van der Sanden <hv@crypt0.demon.co.uk>, |
| 2321 | Gurusamy Sarathy <gsar@activestate.com>, |
| 2322 | Paul J. Schinder <schinder@pobox.com>, |
| 2323 | Michael G Schwern <schwern@pobox.com>, |
| 2324 | Dan Sugalski <dan@sidhe.org>, |
| 2325 | Nathan Torkington <gnat@frii.com>. |
| 2326 | |