| =head1 NAME |
| |
| perlport - Writing portable Perl |
| |
| =head1 DESCRIPTION |
| |
| Perl runs on numerous operating systems. While most of them share |
| much in common, they also have their own unique features. |
| |
| This document is meant to help you to find out what constitutes portable |
| Perl code. That way once you make a decision to write portably, |
| you know where the lines are drawn, and you can stay within them. |
| |
| There is a tradeoff between taking full advantage of one particular |
| type of computer and taking advantage of a full range of them. |
| Naturally, as you broaden your range and become more diverse, the |
| common factors drop, and you are left with an increasingly smaller |
| area of common ground in which you can operate to accomplish a |
| particular task. Thus, when you begin attacking a problem, it is |
| important to consider under which part of the tradeoff curve you |
| want to operate. Specifically, you must decide whether it is |
| important that the task that you are coding have the full generality |
| of being portable, or whether to just get the job done right now. |
| This is the hardest choice to be made. The rest is easy, because |
| Perl provides many choices, whichever way you want to approach your |
| problem. |
| |
| Looking at it another way, writing portable code is usually about |
| willfully limiting your available choices. Naturally, it takes |
| discipline and sacrifice to do that. The product of portability |
| and convenience may be a constant. You have been warned. |
| |
| Be aware of two important points: |
| |
| =over 4 |
| |
| =item Not all Perl programs have to be portable |
| |
| There is no reason you should not use Perl as a language to glue Unix |
| tools together, or to prototype a Macintosh application, or to manage the |
| Windows registry. If it makes no sense to aim for portability for one |
| reason or another in a given program, then don't bother. |
| |
| =item Nearly all of Perl already I<is> portable |
| |
| Don't be fooled into thinking that it is hard to create portable Perl |
| code. It isn't. Perl tries its level-best to bridge the gaps between |
| what's available on different platforms, and all the means available to |
| use those features. Thus almost all Perl code runs on any machine |
| without modification. But there are some significant issues in |
| writing portable code, and this document is entirely about those issues. |
| |
| =back |
| |
| Here's the general rule: When you approach a task commonly done |
| using a whole range of platforms, think about writing portable |
| code. That way, you don't sacrifice much by way of the implementation |
| choices you can avail yourself of, and at the same time you can give |
| your users lots of platform choices. On the other hand, when you have to |
| take advantage of some unique feature of a particular platform, as is |
| often the case with systems programming (whether for Unix, Windows, |
| VMS, etc.), consider writing platform-specific code. |
| |
| When the code will run on only two or three operating systems, you |
| may need to consider only the differences of those particular systems. |
| The important thing is to decide where the code will run and to be |
| deliberate in your decision. |
| |
| The material below is separated into three main sections: main issues of |
| portability (L<"ISSUES">), platform-specific issues (L<"PLATFORMS">), and |
| built-in perl functions that behave differently on various ports |
| (L<"FUNCTION IMPLEMENTATIONS">). |
| |
| This information should not be considered complete; it includes possibly |
| transient information about idiosyncrasies of some of the ports, almost |
| all of which are in a state of constant evolution. Thus, this material |
| should be considered a perpetual work in progress |
| (C<< <IMG SRC="yellow_sign.gif" ALT="Under Construction"> >>). |
| |
| =head1 ISSUES |
| |
| =head2 Newlines |
| |
| In most operating systems, lines in files are terminated by newlines. |
| Just what is used as a newline may vary from OS to OS. Unix |
| traditionally uses C<\012>, one type of DOSish I/O uses C<\015\012>, |
| and S<Mac OS> uses C<\015>. |
| |
| Perl uses C<\n> to represent the "logical" newline, where what is |
| logical may depend on the platform in use. In MacPerl, C<\n> always |
| means C<\015>. In DOSish perls, C<\n> usually means C<\012>, but when |
| accessing a file in "text" mode, perl uses the C<:crlf> layer that |
| translates it to (or from) C<\015\012>, depending on whether you're |
| reading or writing. Unix does the same thing on ttys in canonical |
| mode. C<\015\012> is commonly referred to as CRLF. |
| |
| To trim trailing newlines from text lines use chomp(). With default |
| settings that function looks for a trailing C<\n> character and thus |
| trims in a portable way. |
| |
| When dealing with binary files (or text files in binary mode) be sure |
| to explicitly set $/ to the appropriate value for your file format |
| before using chomp(). |
| |
| Because of the "text" mode translation, DOSish perls have limitations |
| in using C<seek> and C<tell> on a file accessed in "text" mode. |
| Stick to C<seek>-ing to locations you got from C<tell> (and no |
| others), and you are usually free to use C<seek> and C<tell> even |
| in "text" mode. Using C<seek> or C<tell> or other file operations |
| may be non-portable. If you use C<binmode> on a file, however, you |
| can usually C<seek> and C<tell> with arbitrary values in safety. |
| |
| A common misconception in socket programming is that C<\n> eq C<\012> |
| everywhere. When using protocols such as common Internet protocols, |
| C<\012> and C<\015> are called for specifically, and the values of |
| the logical C<\n> and C<\r> (carriage return) are not reliable. |
| |
| print SOCKET "Hi there, client!\r\n"; # WRONG |
| print SOCKET "Hi there, client!\015\012"; # RIGHT |
| |
| However, using C<\015\012> (or C<\cM\cJ>, or C<\x0D\x0A>) can be tedious |
| and unsightly, as well as confusing to those maintaining the code. As |
| such, the Socket module supplies the Right Thing for those who want it. |
| |
| use Socket qw(:DEFAULT :crlf); |
| print SOCKET "Hi there, client!$CRLF" # RIGHT |
| |
| When reading from a socket, remember that the default input record |
| separator C<$/> is C<\n>, but robust socket code will recognize as |
| either C<\012> or C<\015\012> as end of line: |
| |
| while (<SOCKET>) { |
| # ... |
| } |
| |
| Because both CRLF and LF end in LF, the input record separator can |
| be set to LF and any CR stripped later. Better to write: |
| |
| use Socket qw(:DEFAULT :crlf); |
| local($/) = LF; # not needed if $/ is already \012 |
| |
| while (<SOCKET>) { |
| s/$CR?$LF/\n/; # not sure if socket uses LF or CRLF, OK |
| # s/\015?\012/\n/; # same thing |
| } |
| |
| This example is preferred over the previous one--even for Unix |
| platforms--because now any C<\015>'s (C<\cM>'s) are stripped out |
| (and there was much rejoicing). |
| |
| Similarly, functions that return text data--such as a function that |
| fetches a web page--should sometimes translate newlines before |
| returning the data, if they've not yet been translated to the local |
| newline representation. A single line of code will often suffice: |
| |
| $data =~ s/\015?\012/\n/g; |
| return $data; |
| |
| Some of this may be confusing. Here's a handy reference to the ASCII CR |
| and LF characters. You can print it out and stick it in your wallet. |
| |
| LF eq \012 eq \x0A eq \cJ eq chr(10) eq ASCII 10 |
| CR eq \015 eq \x0D eq \cM eq chr(13) eq ASCII 13 |
| |
| | Unix | DOS | Mac | |
| --------------------------- |
| \n | LF | LF | CR | |
| \r | CR | CR | LF | |
| \n * | LF | CRLF | CR | |
| \r * | CR | CR | LF | |
| --------------------------- |
| * text-mode STDIO |
| |
| The Unix column assumes that you are not accessing a serial line |
| (like a tty) in canonical mode. If you are, then CR on input becomes |
| "\n", and "\n" on output becomes CRLF. |
| |
| These are just the most common definitions of C<\n> and C<\r> in Perl. |
| There may well be others. For example, on an EBCDIC implementation |
| such as z/OS (OS/390) or OS/400 (using the ILE, the PASE is ASCII-based) |
| the above material is similar to "Unix" but the code numbers change: |
| |
| LF eq \025 eq \x15 eq \cU eq chr(21) eq CP-1047 21 |
| LF eq \045 eq \x25 eq chr(37) eq CP-0037 37 |
| CR eq \015 eq \x0D eq \cM eq chr(13) eq CP-1047 13 |
| CR eq \015 eq \x0D eq \cM eq chr(13) eq CP-0037 13 |
| |
| | z/OS | OS/400 | |
| ---------------------- |
| \n | LF | LF | |
| \r | CR | CR | |
| \n * | LF | LF | |
| \r * | CR | CR | |
| ---------------------- |
| * text-mode STDIO |
| |
| =head2 Numbers endianness and Width |
| |
| Different CPUs store integers and floating point numbers in different |
| orders (called I<endianness>) and widths (32-bit and 64-bit being the |
| most common today). This affects your programs when they attempt to transfer |
| numbers in binary format from one CPU architecture to another, |
| usually either "live" via network connection, or by storing the |
| numbers to secondary storage such as a disk file or tape. |
| |
| Conflicting storage orders make utter mess out of the numbers. If a |
| little-endian host (Intel, VAX) stores 0x12345678 (305419896 in |
| decimal), a big-endian host (Motorola, Sparc, PA) reads it as |
| 0x78563412 (2018915346 in decimal). Alpha and MIPS can be either: |
| Digital/Compaq used/uses them in little-endian mode; SGI/Cray uses |
| them in big-endian mode. To avoid this problem in network (socket) |
| connections use the C<pack> and C<unpack> formats C<n> and C<N>, the |
| "network" orders. These are guaranteed to be portable. |
| |
| As of perl 5.9.2, you can also use the C<E<gt>> and C<E<lt>> modifiers |
| to force big- or little-endian byte-order. This is useful if you want |
| to store signed integers or 64-bit integers, for example. |
| |
| You can explore the endianness of your platform by unpacking a |
| data structure packed in native format such as: |
| |
| print unpack("h*", pack("s2", 1, 2)), "\n"; |
| # '10002000' on e.g. Intel x86 or Alpha 21064 in little-endian mode |
| # '00100020' on e.g. Motorola 68040 |
| |
| If you need to distinguish between endian architectures you could use |
| either of the variables set like so: |
| |
| $is_big_endian = unpack("h*", pack("s", 1)) =~ /01/; |
| $is_little_endian = unpack("h*", pack("s", 1)) =~ /^1/; |
| |
| Differing widths can cause truncation even between platforms of equal |
| endianness. The platform of shorter width loses the upper parts of the |
| number. There is no good solution for this problem except to avoid |
| transferring or storing raw binary numbers. |
| |
| One can circumnavigate both these problems in two ways. Either |
| transfer and store numbers always in text format, instead of raw |
| binary, or else consider using modules like Data::Dumper (included in |
| the standard distribution as of Perl 5.005) and Storable (included as |
| of perl 5.8). Keeping all data as text significantly simplifies matters. |
| |
| The v-strings are portable only up to v2147483647 (0x7FFFFFFF), that's |
| how far EBCDIC, or more precisely UTF-EBCDIC will go. |
| |
| =head2 Files and Filesystems |
| |
| Most platforms these days structure files in a hierarchical fashion. |
| So, it is reasonably safe to assume that all platforms support the |
| notion of a "path" to uniquely identify a file on the system. How |
| that path is really written, though, differs considerably. |
| |
| Although similar, file path specifications differ between Unix, |
| Windows, S<Mac OS>, OS/2, VMS, VOS, S<RISC OS>, and probably others. |
| Unix, for example, is one of the few OSes that has the elegant idea |
| of a single root directory. |
| |
| DOS, OS/2, VMS, VOS, and Windows can work similarly to Unix with C</> |
| as path separator, or in their own idiosyncratic ways (such as having |
| several root directories and various "unrooted" device files such NIL: |
| and LPT:). |
| |
| S<Mac OS> 9 and earlier used C<:> as a path separator instead of C</>. |
| |
| The filesystem may support neither hard links (C<link>) nor |
| symbolic links (C<symlink>, C<readlink>, C<lstat>). |
| |
| The filesystem may support neither access timestamp nor change |
| timestamp (meaning that about the only portable timestamp is the |
| modification timestamp), or one second granularity of any timestamps |
| (e.g. the FAT filesystem limits the time granularity to two seconds). |
| |
| The "inode change timestamp" (the C<-C> filetest) may really be the |
| "creation timestamp" (which it is not in Unix). |
| |
| VOS perl can emulate Unix filenames with C</> as path separator. The |
| native pathname characters greater-than, less-than, number-sign, and |
| percent-sign are always accepted. |
| |
| S<RISC OS> perl can emulate Unix filenames with C</> as path |
| separator, or go native and use C<.> for path separator and C<:> to |
| signal filesystems and disk names. |
| |
| Don't assume Unix filesystem access semantics: that read, write, |
| and execute are all the permissions there are, and even if they exist, |
| that their semantics (for example what do r, w, and x mean on |
| a directory) are the Unix ones. The various Unix/POSIX compatibility |
| layers usually try to make interfaces like chmod() work, but sometimes |
| there simply is no good mapping. |
| |
| If all this is intimidating, have no (well, maybe only a little) |
| fear. There are modules that can help. The File::Spec modules |
| provide methods to do the Right Thing on whatever platform happens |
| to be running the program. |
| |
| use File::Spec::Functions; |
| chdir(updir()); # go up one directory |
| my $file = catfile(curdir(), 'temp', 'file.txt'); |
| # on Unix and Win32, './temp/file.txt' |
| # on Mac OS Classic, ':temp:file.txt' |
| # on VMS, '[.temp]file.txt' |
| |
| File::Spec is available in the standard distribution as of version |
| 5.004_05. File::Spec::Functions is only in File::Spec 0.7 and later, |
| and some versions of perl come with version 0.6. If File::Spec |
| is not updated to 0.7 or later, you must use the object-oriented |
| interface from File::Spec (or upgrade File::Spec). |
| |
| In general, production code should not have file paths hardcoded. |
| Making them user-supplied or read from a configuration file is |
| better, keeping in mind that file path syntax varies on different |
| machines. |
| |
| This is especially noticeable in scripts like Makefiles and test suites, |
| which often assume C</> as a path separator for subdirectories. |
| |
| Also of use is File::Basename from the standard distribution, which |
| splits a pathname into pieces (base filename, full path to directory, |
| and file suffix). |
| |
| Even when on a single platform (if you can call Unix a single platform), |
| remember not to count on the existence or the contents of particular |
| system-specific files or directories, like F</etc/passwd>, |
| F</etc/sendmail.conf>, F</etc/resolv.conf>, or even F</tmp/>. For |
| example, F</etc/passwd> may exist but not contain the encrypted |
| passwords, because the system is using some form of enhanced security. |
| Or it may not contain all the accounts, because the system is using NIS. |
| If code does need to rely on such a file, include a description of the |
| file and its format in the code's documentation, then make it easy for |
| the user to override the default location of the file. |
| |
| Don't assume a text file will end with a newline. They should, |
| but people forget. |
| |
| Do not have two files or directories of the same name with different |
| case, like F<test.pl> and F<Test.pl>, as many platforms have |
| case-insensitive (or at least case-forgiving) filenames. Also, try |
| not to have non-word characters (except for C<.>) in the names, and |
| keep them to the 8.3 convention, for maximum portability, onerous a |
| burden though this may appear. |
| |
| Likewise, when using the AutoSplit module, try to keep your functions to |
| 8.3 naming and case-insensitive conventions; or, at the least, |
| make it so the resulting files have a unique (case-insensitively) |
| first 8 characters. |
| |
| Whitespace in filenames is tolerated on most systems, but not all, |
| and even on systems where it might be tolerated, some utilities |
| might become confused by such whitespace. |
| |
| Many systems (DOS, VMS ODS-2) cannot have more than one C<.> in their |
| filenames. |
| |
| Don't assume C<< > >> won't be the first character of a filename. |
| Always use C<< < >> explicitly to open a file for reading, or even |
| better, use the three-arg version of open, unless you want the user to |
| be able to specify a pipe open. |
| |
| open my $fh, '<', $existing_file) or die $!; |
| |
| If filenames might use strange characters, it is safest to open it |
| with C<sysopen> instead of C<open>. C<open> is magic and can |
| translate characters like C<< > >>, C<< < >>, and C<|>, which may |
| be the wrong thing to do. (Sometimes, though, it's the right thing.) |
| Three-arg open can also help protect against this translation in cases |
| where it is undesirable. |
| |
| Don't use C<:> as a part of a filename since many systems use that for |
| their own semantics (Mac OS Classic for separating pathname components, |
| many networking schemes and utilities for separating the nodename and |
| the pathname, and so on). For the same reasons, avoid C<@>, C<;> and |
| C<|>. |
| |
| Don't assume that in pathnames you can collapse two leading slashes |
| C<//> into one: some networking and clustering filesystems have special |
| semantics for that. Let the operating system to sort it out. |
| |
| The I<portable filename characters> as defined by ANSI C are |
| |
| a b c d e f g h i j k l m n o p q r t u v w x y z |
| A B C D E F G H I J K L M N O P Q R T U V W X Y Z |
| 0 1 2 3 4 5 6 7 8 9 |
| . _ - |
| |
| and the "-" shouldn't be the first character. If you want to be |
| hypercorrect, stay case-insensitive and within the 8.3 naming |
| convention (all the files and directories have to be unique within one |
| directory if their names are lowercased and truncated to eight |
| characters before the C<.>, if any, and to three characters after the |
| C<.>, if any). (And do not use C<.>s in directory names.) |
| |
| =head2 System Interaction |
| |
| Not all platforms provide a command line. These are usually platforms |
| that rely primarily on a Graphical User Interface (GUI) for user |
| interaction. A program requiring a command line interface might |
| not work everywhere. This is probably for the user of the program |
| to deal with, so don't stay up late worrying about it. |
| |
| Some platforms can't delete or rename files held open by the system, |
| this limitation may also apply to changing filesystem metainformation |
| like file permissions or owners. Remember to C<close> files when you |
| are done with them. Don't C<unlink> or C<rename> an open file. Don't |
| C<tie> or C<open> a file already tied or opened; C<untie> or C<close> |
| it first. |
| |
| Don't open the same file more than once at a time for writing, as some |
| operating systems put mandatory locks on such files. |
| |
| Don't assume that write/modify permission on a directory gives the |
| right to add or delete files/directories in that directory. That is |
| filesystem specific: in some filesystems you need write/modify |
| permission also (or even just) in the file/directory itself. In some |
| filesystems (AFS, DFS) the permission to add/delete directory entries |
| is a completely separate permission. |
| |
| Don't assume that a single C<unlink> completely gets rid of the file: |
| some filesystems (most notably the ones in VMS) have versioned |
| filesystems, and unlink() removes only the most recent one (it doesn't |
| remove all the versions because by default the native tools on those |
| platforms remove just the most recent version, too). The portable |
| idiom to remove all the versions of a file is |
| |
| 1 while unlink "file"; |
| |
| This will terminate if the file is undeleteable for some reason |
| (protected, not there, and so on). |
| |
| Don't count on a specific environment variable existing in C<%ENV>. |
| Don't count on C<%ENV> entries being case-sensitive, or even |
| case-preserving. Don't try to clear %ENV by saying C<%ENV = ();>, or, |
| if you really have to, make it conditional on C<$^O ne 'VMS'> since in |
| VMS the C<%ENV> table is much more than a per-process key-value string |
| table. |
| |
| On VMS, some entries in the %ENV hash are dynamically created when |
| their key is used on a read if they did not previously exist. The |
| values for C<$ENV{HOME}>, C<$ENV{TERM}>, C<$ENV{HOME}>, and C<$ENV{USER}>, |
| are known to be dynamically generated. The specific names that are |
| dynamically generated may vary with the version of the C library on VMS, |
| and more may exist than is documented. |
| |
| On VMS by default, changes to the %ENV hash are persistent after the process |
| exits. This can cause unintended issues. |
| |
| Don't count on signals or C<%SIG> for anything. |
| |
| Don't count on filename globbing. Use C<opendir>, C<readdir>, and |
| C<closedir> instead. |
| |
| Don't count on per-program environment variables, or per-program current |
| directories. |
| |
| Don't count on specific values of C<$!>, neither numeric nor |
| especially the strings values. Users may switch their locales causing |
| error messages to be translated into their languages. If you can |
| trust a POSIXish environment, you can portably use the symbols defined |
| by the Errno module, like ENOENT. And don't trust on the values of C<$!> |
| at all except immediately after a failed system call. |
| |
| =head2 Command names versus file pathnames |
| |
| Don't assume that the name used to invoke a command or program with |
| C<system> or C<exec> can also be used to test for the existence of the |
| file that holds the executable code for that command or program. |
| First, many systems have "internal" commands that are built-in to the |
| shell or OS and while these commands can be invoked, there is no |
| corresponding file. Second, some operating systems (e.g., Cygwin, |
| DJGPP, OS/2, and VOS) have required suffixes for executable files; |
| these suffixes are generally permitted on the command name but are not |
| required. Thus, a command like "perl" might exist in a file named |
| "perl", "perl.exe", or "perl.pm", depending on the operating system. |
| The variable "_exe" in the Config module holds the executable suffix, |
| if any. Third, the VMS port carefully sets up $^X and |
| $Config{perlpath} so that no further processing is required. This is |
| just as well, because the matching regular expression used below would |
| then have to deal with a possible trailing version number in the VMS |
| file name. |
| |
| To convert $^X to a file pathname, taking account of the requirements |
| of the various operating system possibilities, say: |
| |
| use Config; |
| my $thisperl = $^X; |
| if ($^O ne 'VMS') |
| {$thisperl .= $Config{_exe} unless $thisperl =~ m/$Config{_exe}$/i;} |
| |
| To convert $Config{perlpath} to a file pathname, say: |
| |
| use Config; |
| my $thisperl = $Config{perlpath}; |
| if ($^O ne 'VMS') |
| {$thisperl .= $Config{_exe} unless $thisperl =~ m/$Config{_exe}$/i;} |
| |
| =head2 Networking |
| |
| Don't assume that you can reach the public Internet. |
| |
| Don't assume that there is only one way to get through firewalls |
| to the public Internet. |
| |
| Don't assume that you can reach outside world through any other port |
| than 80, or some web proxy. ftp is blocked by many firewalls. |
| |
| Don't assume that you can send email by connecting to the local SMTP port. |
| |
| Don't assume that you can reach yourself or any node by the name |
| 'localhost'. The same goes for '127.0.0.1'. You will have to try both. |
| |
| Don't assume that the host has only one network card, or that it |
| can't bind to many virtual IP addresses. |
| |
| Don't assume a particular network device name. |
| |
| Don't assume a particular set of ioctl()s will work. |
| |
| Don't assume that you can ping hosts and get replies. |
| |
| Don't assume that any particular port (service) will respond. |
| |
| Don't assume that Sys::Hostname (or any other API or command) returns |
| either a fully qualified hostname or a non-qualified hostname: it all |
| depends on how the system had been configured. Also remember that for |
| things such as DHCP and NAT, the hostname you get back might not be |
| very useful. |
| |
| All the above "don't":s may look daunting, and they are, but the key |
| is to degrade gracefully if one cannot reach the particular network |
| service one wants. Croaking or hanging do not look very professional. |
| |
| =head2 Interprocess Communication (IPC) |
| |
| In general, don't directly access the system in code meant to be |
| portable. That means, no C<system>, C<exec>, C<fork>, C<pipe>, |
| C<``>, C<qx//>, C<open> with a C<|>, nor any of the other things |
| that makes being a perl hacker worth being. |
| |
| Commands that launch external processes are generally supported on |
| most platforms (though many of them do not support any type of |
| forking). The problem with using them arises from what you invoke |
| them on. External tools are often named differently on different |
| platforms, may not be available in the same location, might accept |
| different arguments, can behave differently, and often present their |
| results in a platform-dependent way. Thus, you should seldom depend |
| on them to produce consistent results. (Then again, if you're calling |
| I<netstat -a>, you probably don't expect it to run on both Unix and CP/M.) |
| |
| One especially common bit of Perl code is opening a pipe to B<sendmail>: |
| |
| open(MAIL, '|/usr/lib/sendmail -t') |
| or die "cannot fork sendmail: $!"; |
| |
| This is fine for systems programming when sendmail is known to be |
| available. But it is not fine for many non-Unix systems, and even |
| some Unix systems that may not have sendmail installed. If a portable |
| solution is needed, see the various distributions on CPAN that deal |
| with it. Mail::Mailer and Mail::Send in the MailTools distribution are |
| commonly used, and provide several mailing methods, including mail, |
| sendmail, and direct SMTP (via Net::SMTP) if a mail transfer agent is |
| not available. Mail::Sendmail is a standalone module that provides |
| simple, platform-independent mailing. |
| |
| The Unix System V IPC (C<msg*(), sem*(), shm*()>) is not available |
| even on all Unix platforms. |
| |
| Do not use either the bare result of C<pack("N", 10, 20, 30, 40)> or |
| bare v-strings (such as C<v10.20.30.40>) to represent IPv4 addresses: |
| both forms just pack the four bytes into network order. That this |
| would be equal to the C language C<in_addr> struct (which is what the |
| socket code internally uses) is not guaranteed. To be portable use |
| the routines of the Socket extension, such as C<inet_aton()>, |
| C<inet_ntoa()>, and C<sockaddr_in()>. |
| |
| The rule of thumb for portable code is: Do it all in portable Perl, or |
| use a module (that may internally implement it with platform-specific |
| code, but expose a common interface). |
| |
| =head2 External Subroutines (XS) |
| |
| XS code can usually be made to work with any platform, but dependent |
| libraries, header files, etc., might not be readily available or |
| portable, or the XS code itself might be platform-specific, just as Perl |
| code might be. If the libraries and headers are portable, then it is |
| normally reasonable to make sure the XS code is portable, too. |
| |
| A different type of portability issue arises when writing XS code: |
| availability of a C compiler on the end-user's system. C brings |
| with it its own portability issues, and writing XS code will expose |
| you to some of those. Writing purely in Perl is an easier way to |
| achieve portability. |
| |
| =head2 Standard Modules |
| |
| In general, the standard modules work across platforms. Notable |
| exceptions are the CPAN module (which currently makes connections to external |
| programs that may not be available), platform-specific modules (like |
| ExtUtils::MM_VMS), and DBM modules. |
| |
| There is no one DBM module available on all platforms. |
| SDBM_File and the others are generally available on all Unix and DOSish |
| ports, but not in MacPerl, where only NBDM_File and DB_File are |
| available. |
| |
| The good news is that at least some DBM module should be available, and |
| AnyDBM_File will use whichever module it can find. Of course, then |
| the code needs to be fairly strict, dropping to the greatest common |
| factor (e.g., not exceeding 1K for each record), so that it will |
| work with any DBM module. See L<AnyDBM_File> for more details. |
| |
| =head2 Time and Date |
| |
| The system's notion of time of day and calendar date is controlled in |
| widely different ways. Don't assume the timezone is stored in C<$ENV{TZ}>, |
| and even if it is, don't assume that you can control the timezone through |
| that variable. Don't assume anything about the three-letter timezone |
| abbreviations (for example that MST would be the Mountain Standard Time, |
| it's been known to stand for Moscow Standard Time). If you need to |
| use timezones, express them in some unambiguous format like the |
| exact number of minutes offset from UTC, or the POSIX timezone |
| format. |
| |
| Don't assume that the epoch starts at 00:00:00, January 1, 1970, |
| because that is OS- and implementation-specific. It is better to |
| store a date in an unambiguous representation. The ISO 8601 standard |
| defines YYYY-MM-DD as the date format, or YYYY-MM-DDTHH:MM:SS |
| (that's a literal "T" separating the date from the time). |
| Please do use the ISO 8601 instead of making us guess what |
| date 02/03/04 might be. ISO 8601 even sorts nicely as-is. |
| A text representation (like "1987-12-18") can be easily converted |
| into an OS-specific value using a module like Date::Parse. |
| An array of values, such as those returned by C<localtime>, can be |
| converted to an OS-specific representation using Time::Local. |
| |
| When calculating specific times, such as for tests in time or date modules, |
| it may be appropriate to calculate an offset for the epoch. |
| |
| require Time::Local; |
| my $offset = Time::Local::timegm(0, 0, 0, 1, 0, 70); |
| |
| The value for C<$offset> in Unix will be C<0>, but in Mac OS Classic |
| will be some large number. C<$offset> can then be added to a Unix time |
| value to get what should be the proper value on any system. |
| |
| =head2 Character sets and character encoding |
| |
| Assume very little about character sets. |
| |
| Assume nothing about numerical values (C<ord>, C<chr>) of characters. |
| Do not use explicit code point ranges (like \xHH-\xHH); use for |
| example symbolic character classes like C<[:print:]>. |
| |
| Do not assume that the alphabetic characters are encoded contiguously |
| (in the numeric sense). There may be gaps. |
| |
| Do not assume anything about the ordering of the characters. |
| The lowercase letters may come before or after the uppercase letters; |
| the lowercase and uppercase may be interlaced so that both "a" and "A" |
| come before "b"; the accented and other international characters may |
| be interlaced so that E<auml> comes before "b". |
| |
| =head2 Internationalisation |
| |
| If you may assume POSIX (a rather large assumption), you may read |
| more about the POSIX locale system from L<perllocale>. The locale |
| system at least attempts to make things a little bit more portable, |
| or at least more convenient and native-friendly for non-English |
| users. The system affects character sets and encoding, and date |
| and time formatting--amongst other things. |
| |
| If you really want to be international, you should consider Unicode. |
| See L<perluniintro> and L<perlunicode> for more information. |
| |
| If you want to use non-ASCII bytes (outside the bytes 0x00..0x7f) in |
| the "source code" of your code, to be portable you have to be explicit |
| about what bytes they are. Someone might for example be using your |
| code under a UTF-8 locale, in which case random native bytes might be |
| illegal ("Malformed UTF-8 ...") This means that for example embedding |
| ISO 8859-1 bytes beyond 0x7f into your strings might cause trouble |
| later. If the bytes are native 8-bit bytes, you can use the C<bytes> |
| pragma. If the bytes are in a string (regular expression being a |
| curious string), you can often also use the C<\xHH> notation instead |
| of embedding the bytes as-is. (If you want to write your code in UTF-8, |
| you can use the C<utf8>.) The C<bytes> and C<utf8> pragmata are |
| available since Perl 5.6.0. |
| |
| =head2 System Resources |
| |
| If your code is destined for systems with severely constrained (or |
| missing!) virtual memory systems then you want to be I<especially> mindful |
| of avoiding wasteful constructs such as: |
| |
| my @lines = <$very_large_file>; # bad |
| |
| while (<$fh>) {$file .= $_} # sometimes bad |
| my $file = join('', <$fh>); # better |
| |
| The last two constructs may appear unintuitive to most people. The |
| first repeatedly grows a string, whereas the second allocates a |
| large chunk of memory in one go. On some systems, the second is |
| more efficient that the first. |
| |
| =head2 Security |
| |
| Most multi-user platforms provide basic levels of security, usually |
| implemented at the filesystem level. Some, however, unfortunately do |
| not. Thus the notion of user id, or "home" directory, |
| or even the state of being logged-in, may be unrecognizable on many |
| platforms. If you write programs that are security-conscious, it |
| is usually best to know what type of system you will be running |
| under so that you can write code explicitly for that platform (or |
| class of platforms). |
| |
| Don't assume the Unix filesystem access semantics: the operating |
| system or the filesystem may be using some ACL systems, which are |
| richer languages than the usual rwx. Even if the rwx exist, |
| their semantics might be different. |
| |
| (From security viewpoint testing for permissions before attempting to |
| do something is silly anyway: if one tries this, there is potential |
| for race conditions. Someone or something might change the |
| permissions between the permissions check and the actual operation. |
| Just try the operation.) |
| |
| Don't assume the Unix user and group semantics: especially, don't |
| expect the C<< $< >> and C<< $> >> (or the C<$(> and C<$)>) to work |
| for switching identities (or memberships). |
| |
| Don't assume set-uid and set-gid semantics. (And even if you do, |
| think twice: set-uid and set-gid are a known can of security worms.) |
| |
| =head2 Style |
| |
| For those times when it is necessary to have platform-specific code, |
| consider keeping the platform-specific code in one place, making porting |
| to other platforms easier. Use the Config module and the special |
| variable C<$^O> to differentiate platforms, as described in |
| L<"PLATFORMS">. |
| |
| Be careful in the tests you supply with your module or programs. |
| Module code may be fully portable, but its tests might not be. This |
| often happens when tests spawn off other processes or call external |
| programs to aid in the testing, or when (as noted above) the tests |
| assume certain things about the filesystem and paths. Be careful not |
| to depend on a specific output style for errors, such as when checking |
| C<$!> after a failed system call. Using C<$!> for anything else than |
| displaying it as output is doubtful (though see the Errno module for |
| testing reasonably portably for error value). Some platforms expect |
| a certain output format, and Perl on those platforms may have been |
| adjusted accordingly. Most specifically, don't anchor a regex when |
| testing an error value. |
| |
| =head1 CPAN Testers |
| |
| Modules uploaded to CPAN are tested by a variety of volunteers on |
| different platforms. These CPAN testers are notified by mail of each |
| new upload, and reply to the list with PASS, FAIL, NA (not applicable to |
| this platform), or UNKNOWN (unknown), along with any relevant notations. |
| |
| The purpose of the testing is twofold: one, to help developers fix any |
| problems in their code that crop up because of lack of testing on other |
| platforms; two, to provide users with information about whether |
| a given module works on a given platform. |
| |
| Also see: |
| |
| =over 4 |
| |
| =item * |
| |
| Mailing list: cpan-testers-discuss@perl.org |
| |
| =item * |
| |
| Testing results: L<http://www.cpantesters.org/> |
| |
| =back |
| |
| =head1 PLATFORMS |
| |
| As of version 5.002, Perl is built with a C<$^O> variable that |
| indicates the operating system it was built on. This was implemented |
| to help speed up code that would otherwise have to C<use Config> |
| and use the value of C<$Config{osname}>. Of course, to get more |
| detailed information about the system, looking into C<%Config> is |
| certainly recommended. |
| |
| C<%Config> cannot always be trusted, however, because it was built |
| at compile time. If perl was built in one place, then transferred |
| elsewhere, some values may be wrong. The values may even have been |
| edited after the fact. |
| |
| =head2 Unix |
| |
| Perl works on a bewildering variety of Unix and Unix-like platforms (see |
| e.g. most of the files in the F<hints/> directory in the source code kit). |
| On most of these systems, the value of C<$^O> (hence C<$Config{'osname'}>, |
| too) is determined either by lowercasing and stripping punctuation from the |
| first field of the string returned by typing C<uname -a> (or a similar command) |
| at the shell prompt or by testing the file system for the presence of |
| uniquely named files such as a kernel or header file. Here, for example, |
| are a few of the more popular Unix flavors: |
| |
| uname $^O $Config{'archname'} |
| -------------------------------------------- |
| AIX aix aix |
| BSD/OS bsdos i386-bsdos |
| Darwin darwin darwin |
| dgux dgux AViiON-dgux |
| DYNIX/ptx dynixptx i386-dynixptx |
| FreeBSD freebsd freebsd-i386 |
| Haiku haiku BePC-haiku |
| Linux linux arm-linux |
| Linux linux i386-linux |
| Linux linux i586-linux |
| Linux linux ppc-linux |
| HP-UX hpux PA-RISC1.1 |
| IRIX irix irix |
| Mac OS X darwin darwin |
| NeXT 3 next next-fat |
| NeXT 4 next OPENSTEP-Mach |
| openbsd openbsd i386-openbsd |
| OSF1 dec_osf alpha-dec_osf |
| reliantunix-n svr4 RM400-svr4 |
| SCO_SV sco_sv i386-sco_sv |
| SINIX-N svr4 RM400-svr4 |
| sn4609 unicos CRAY_C90-unicos |
| sn6521 unicosmk t3e-unicosmk |
| sn9617 unicos CRAY_J90-unicos |
| SunOS solaris sun4-solaris |
| SunOS solaris i86pc-solaris |
| SunOS4 sunos sun4-sunos |
| |
| Because the value of C<$Config{archname}> may depend on the |
| hardware architecture, it can vary more than the value of C<$^O>. |
| |
| =head2 DOS and Derivatives |
| |
| Perl has long been ported to Intel-style microcomputers running under |
| systems like PC-DOS, MS-DOS, OS/2, and most Windows platforms you can |
| bring yourself to mention (except for Windows CE, if you count that). |
| Users familiar with I<COMMAND.COM> or I<CMD.EXE> style shells should |
| be aware that each of these file specifications may have subtle |
| differences: |
| |
| my $filespec0 = "c:/foo/bar/file.txt"; |
| my $filespec1 = "c:\\foo\\bar\\file.txt"; |
| my $filespec2 = 'c:\foo\bar\file.txt'; |
| my $filespec3 = 'c:\\foo\\bar\\file.txt'; |
| |
| System calls accept either C</> or C<\> as the path separator. |
| However, many command-line utilities of DOS vintage treat C</> as |
| the option prefix, so may get confused by filenames containing C</>. |
| Aside from calling any external programs, C</> will work just fine, |
| and probably better, as it is more consistent with popular usage, |
| and avoids the problem of remembering what to backwhack and what |
| not to. |
| |
| The DOS FAT filesystem can accommodate only "8.3" style filenames. Under |
| the "case-insensitive, but case-preserving" HPFS (OS/2) and NTFS (NT) |
| filesystems you may have to be careful about case returned with functions |
| like C<readdir> or used with functions like C<open> or C<opendir>. |
| |
| DOS also treats several filenames as special, such as AUX, PRN, |
| NUL, CON, COM1, LPT1, LPT2, etc. Unfortunately, sometimes these |
| filenames won't even work if you include an explicit directory |
| prefix. It is best to avoid such filenames, if you want your code |
| to be portable to DOS and its derivatives. It's hard to know what |
| these all are, unfortunately. |
| |
| Users of these operating systems may also wish to make use of |
| scripts such as I<pl2bat.bat> or I<pl2cmd> to |
| put wrappers around your scripts. |
| |
| Newline (C<\n>) is translated as C<\015\012> by STDIO when reading from |
| and writing to files (see L<"Newlines">). C<binmode(FILEHANDLE)> |
| will keep C<\n> translated as C<\012> for that filehandle. Since it is a |
| no-op on other systems, C<binmode> should be used for cross-platform code |
| that deals with binary data. That's assuming you realize in advance |
| that your data is in binary. General-purpose programs should |
| often assume nothing about their data. |
| |
| The C<$^O> variable and the C<$Config{archname}> values for various |
| DOSish perls are as follows: |
| |
| OS $^O $Config{archname} ID Version |
| -------------------------------------------------------- |
| MS-DOS dos ? |
| PC-DOS dos ? |
| OS/2 os2 ? |
| Windows 3.1 ? ? 0 3 01 |
| Windows 95 MSWin32 MSWin32-x86 1 4 00 |
| Windows 98 MSWin32 MSWin32-x86 1 4 10 |
| Windows ME MSWin32 MSWin32-x86 1 ? |
| Windows NT MSWin32 MSWin32-x86 2 4 xx |
| Windows NT MSWin32 MSWin32-ALPHA 2 4 xx |
| Windows NT MSWin32 MSWin32-ppc 2 4 xx |
| Windows 2000 MSWin32 MSWin32-x86 2 5 00 |
| Windows XP MSWin32 MSWin32-x86 2 5 01 |
| Windows 2003 MSWin32 MSWin32-x86 2 5 02 |
| Windows Vista MSWin32 MSWin32-x86 2 6 00 |
| Windows 7 MSWin32 MSWin32-x86 2 6 01 |
| Windows 7 MSWin32 MSWin32-x64 2 6 01 |
| Windows 2008 MSWin32 MSWin32-x86 2 6 01 |
| Windows 2008 MSWin32 MSWin32-x64 2 6 01 |
| Windows CE MSWin32 ? 3 |
| Cygwin cygwin cygwin |
| |
| The various MSWin32 Perl's can distinguish the OS they are running on |
| via the value of the fifth element of the list returned from |
| Win32::GetOSVersion(). For example: |
| |
| if ($^O eq 'MSWin32') { |
| my @os_version_info = Win32::GetOSVersion(); |
| print +('3.1','95','NT')[$os_version_info[4]],"\n"; |
| } |
| |
| There are also Win32::IsWinNT() and Win32::IsWin95(), try C<perldoc Win32>, |
| and as of libwin32 0.19 (not part of the core Perl distribution) |
| Win32::GetOSName(). The very portable POSIX::uname() will work too: |
| |
| c:\> perl -MPOSIX -we "print join '|', uname" |
| Windows NT|moonru|5.0|Build 2195 (Service Pack 2)|x86 |
| |
| Also see: |
| |
| =over 4 |
| |
| =item * |
| |
| The djgpp environment for DOS, L<http://www.delorie.com/djgpp/> |
| and L<perldos>. |
| |
| =item * |
| |
| The EMX environment for DOS, OS/2, etc. emx@iaehv.nl, |
| L<ftp://hobbes.nmsu.edu/pub/os2/dev/emx/> Also L<perlos2>. |
| |
| =item * |
| |
| Build instructions for Win32 in L<perlwin32>, or under the Cygnus environment |
| in L<perlcygwin>. |
| |
| =item * |
| |
| The C<Win32::*> modules in L<Win32>. |
| |
| =item * |
| |
| The ActiveState Pages, L<http://www.activestate.com/> |
| |
| =item * |
| |
| The Cygwin environment for Win32; F<README.cygwin> (installed |
| as L<perlcygwin>), L<http://www.cygwin.com/> |
| |
| =item * |
| |
| The U/WIN environment for Win32, |
| L<http://www.research.att.com/sw/tools/uwin/> |
| |
| =item * |
| |
| Build instructions for OS/2, L<perlos2> |
| |
| =back |
| |
| =head2 VMS |
| |
| Perl on VMS is discussed in L<perlvms> in the perl distribution. |
| |
| The official name of VMS as of this writing is OpenVMS. |
| |
| Perl on VMS can accept either VMS- or Unix-style file |
| specifications as in either of the following: |
| |
| $ perl -ne "print if /perl_setup/i" SYS$LOGIN:LOGIN.COM |
| $ perl -ne "print if /perl_setup/i" /sys$login/login.com |
| |
| but not a mixture of both as in: |
| |
| $ perl -ne "print if /perl_setup/i" sys$login:/login.com |
| Can't open sys$login:/login.com: file specification syntax error |
| |
| Interacting with Perl from the Digital Command Language (DCL) shell |
| often requires a different set of quotation marks than Unix shells do. |
| For example: |
| |
| $ perl -e "print ""Hello, world.\n""" |
| Hello, world. |
| |
| There are several ways to wrap your perl scripts in DCL F<.COM> files, if |
| you are so inclined. For example: |
| |
| $ write sys$output "Hello from DCL!" |
| $ if p1 .eqs. "" |
| $ then perl -x 'f$environment("PROCEDURE") |
| $ else perl -x - 'p1 'p2 'p3 'p4 'p5 'p6 'p7 'p8 |
| $ deck/dollars="__END__" |
| #!/usr/bin/perl |
| |
| print "Hello from Perl!\n"; |
| |
| __END__ |
| $ endif |
| |
| Do take care with C<$ ASSIGN/nolog/user SYS$COMMAND: SYS$INPUT> if your |
| perl-in-DCL script expects to do things like C<< $read = <STDIN>; >>. |
| |
| The VMS operating system has two filesystems, known as ODS-2 and ODS-5. |
| |
| For ODS-2, filenames are in the format "name.extension;version". The |
| maximum length for filenames is 39 characters, and the maximum length for |
| extensions is also 39 characters. Version is a number from 1 to |
| 32767. Valid characters are C</[A-Z0-9$_-]/>. |
| |
| The ODS-2 filesystem is case-insensitive and does not preserve case. |
| Perl simulates this by converting all filenames to lowercase internally. |
| |
| For ODS-5, filenames may have almost any character in them and can include |
| Unicode characters. Characters that could be misinterpreted by the DCL |
| shell or file parsing utilities need to be prefixed with the C<^> |
| character, or replaced with hexadecimal characters prefixed with the |
| C<^> character. Such prefixing is only needed with the pathnames are |
| in VMS format in applications. Programs that can accept the Unix format |
| of pathnames do not need the escape characters. The maximum length for |
| filenames is 255 characters. The ODS-5 file system can handle both |
| a case preserved and a case sensitive mode. |
| |
| ODS-5 is only available on the OpenVMS for 64 bit platforms. |
| |
| Support for the extended file specifications is being done as optional |
| settings to preserve backward compatibility with Perl scripts that |
| assume the previous VMS limitations. |
| |
| In general routines on VMS that get a Unix format file specification |
| should return it in a Unix format, and when they get a VMS format |
| specification they should return a VMS format unless they are documented |
| to do a conversion. |
| |
| For routines that generate return a file specification, VMS allows setting |
| if the C library which Perl is built on if it will be returned in VMS |
| format or in Unix format. |
| |
| With the ODS-2 file system, there is not much difference in syntax of |
| filenames without paths for VMS or Unix. With the extended character |
| set available with ODS-5 there can be a significant difference. |
| |
| Because of this, existing Perl scripts written for VMS were sometimes |
| treating VMS and Unix filenames interchangeably. Without the extended |
| character set enabled, this behavior will mostly be maintained for |
| backwards compatibility. |
| |
| When extended characters are enabled with ODS-5, the handling of |
| Unix formatted file specifications is to that of a Unix system. |
| |
| VMS file specifications without extensions have a trailing dot. An |
| equivalent Unix file specification should not show the trailing dot. |
| |
| The result of all of this, is that for VMS, for portable scripts, you |
| can not depend on Perl to present the filenames in lowercase, to be |
| case sensitive, and that the filenames could be returned in either |
| Unix or VMS format. |
| |
| And if a routine returns a file specification, unless it is intended to |
| convert it, it should return it in the same format as it found it. |
| |
| C<readdir> by default has traditionally returned lowercased filenames. |
| When the ODS-5 support is enabled, it will return the exact case of the |
| filename on the disk. |
| |
| Files without extensions have a trailing period on them, so doing a |
| C<readdir> in the default mode with a file named F<A.;5> will |
| return F<a.> when VMS is (though that file could be opened with |
| C<open(FH, 'A')>). |
| |
| With support for extended file specifications and if C<opendir> was |
| given a Unix format directory, a file named F<A.;5> will return F<a> |
| and optionally in the exact case on the disk. When C<opendir> is given |
| a VMS format directory, then C<readdir> should return F<a.>, and |
| again with the optionally the exact case. |
| |
| RMS had an eight level limit on directory depths from any rooted logical |
| (allowing 16 levels overall) prior to VMS 7.2, and even with versions of |
| VMS on VAX up through 7.3. Hence C<PERL_ROOT:[LIB.2.3.4.5.6.7.8]> is a |
| valid directory specification but C<PERL_ROOT:[LIB.2.3.4.5.6.7.8.9]> is |
| not. F<Makefile.PL> authors might have to take this into account, but at |
| least they can refer to the former as C</PERL_ROOT/lib/2/3/4/5/6/7/8/>. |
| |
| Pumpkings and module integrators can easily see whether files with too many |
| directory levels have snuck into the core by running the following in the |
| top-level source directory: |
| |
| $ perl -ne "$_=~s/\s+.*//; print if scalar(split /\//) > 8;" < MANIFEST |
| |
| |
| The VMS::Filespec module, which gets installed as part of the build |
| process on VMS, is a pure Perl module that can easily be installed on |
| non-VMS platforms and can be helpful for conversions to and from RMS |
| native formats. It is also now the only way that you should check to |
| see if VMS is in a case sensitive mode. |
| |
| What C<\n> represents depends on the type of file opened. It usually |
| represents C<\012> but it could also be C<\015>, C<\012>, C<\015\012>, |
| C<\000>, C<\040>, or nothing depending on the file organization and |
| record format. The VMS::Stdio module provides access to the |
| special fopen() requirements of files with unusual attributes on VMS. |
| |
| TCP/IP stacks are optional on VMS, so socket routines might not be |
| implemented. UDP sockets may not be supported. |
| |
| The TCP/IP library support for all current versions of VMS is dynamically |
| loaded if present, so even if the routines are configured, they may |
| return a status indicating that they are not implemented. |
| |
| The value of C<$^O> on OpenVMS is "VMS". To determine the architecture |
| that you are running on without resorting to loading all of C<%Config> |
| you can examine the content of the C<@INC> array like so: |
| |
| if (grep(/VMS_AXP/, @INC)) { |
| print "I'm on Alpha!\n"; |
| |
| } elsif (grep(/VMS_VAX/, @INC)) { |
| print "I'm on VAX!\n"; |
| |
| } elsif (grep(/VMS_IA64/, @INC)) { |
| print "I'm on IA64!\n"; |
| |
| } else { |
| print "I'm not so sure about where $^O is...\n"; |
| } |
| |
| In general, the significant differences should only be if Perl is running |
| on VMS_VAX or one of the 64 bit OpenVMS platforms. |
| |
| On VMS, perl determines the UTC offset from the C<SYS$TIMEZONE_DIFFERENTIAL> |
| logical name. Although the VMS epoch began at 17-NOV-1858 00:00:00.00, |
| calls to C<localtime> are adjusted to count offsets from |
| 01-JAN-1970 00:00:00.00, just like Unix. |
| |
| Also see: |
| |
| =over 4 |
| |
| =item * |
| |
| F<README.vms> (installed as F<README_vms>), L<perlvms> |
| |
| =item * |
| |
| vmsperl list, vmsperl-subscribe@perl.org |
| |
| =item * |
| |
| vmsperl on the web, L<http://www.sidhe.org/vmsperl/index.html> |
| |
| =back |
| |
| =head2 VOS |
| |
| Perl on VOS (also known as OpenVOS) is discussed in F<README.vos> |
| in the perl distribution (installed as L<perlvos>). Perl on VOS |
| can accept either VOS- or Unix-style file specifications as in |
| either of the following: |
| |
| $ perl -ne "print if /perl_setup/i" >system>notices |
| $ perl -ne "print if /perl_setup/i" /system/notices |
| |
| or even a mixture of both as in: |
| |
| $ perl -ne "print if /perl_setup/i" >system/notices |
| |
| Even though VOS allows the slash character to appear in object |
| names, because the VOS port of Perl interprets it as a pathname |
| delimiting character, VOS files, directories, or links whose |
| names contain a slash character cannot be processed. Such files |
| must be renamed before they can be processed by Perl. |
| |
| Older releases of VOS (prior to OpenVOS Release 17.0) limit file |
| names to 32 or fewer characters, prohibit file names from |
| starting with a C<-> character, and prohibit file names from |
| containing any character matching C<< tr/ !#%&'()*;<=>?// >>. |
| |
| Newer releases of VOS (OpenVOS Release 17.0 or later) support a |
| feature known as extended names. On these releases, file names |
| can contain up to 255 characters, are prohibited from starting |
| with a C<-> character, and the set of prohibited characters is |
| reduced to any character matching C<< tr/#%*<>?// >>. There are |
| restrictions involving spaces and apostrophes: these characters |
| must not begin or end a name, nor can they immediately precede or |
| follow a period. Additionally, a space must not immediately |
| precede another space or hyphen. Specifically, the following |
| character combinations are prohibited: space-space, |
| space-hyphen, period-space, space-period, period-apostrophe, |
| apostrophe-period, leading or trailing space, and leading or |
| trailing apostrophe. Although an extended file name is limited |
| to 255 characters, a path name is still limited to 256 |
| characters. |
| |
| The value of C<$^O> on VOS is "VOS". To determine the |
| architecture that you are running on without resorting to loading |
| all of C<%Config> you can examine the content of the @INC array |
| like so: |
| |
| if ($^O =~ /VOS/) { |
| print "I'm on a Stratus box!\n"; |
| } else { |
| print "I'm not on a Stratus box!\n"; |
| die; |
| } |
| |
| Also see: |
| |
| =over 4 |
| |
| =item * |
| |
| F<README.vos> (installed as L<perlvos>) |
| |
| =item * |
| |
| The VOS mailing list. |
| |
| There is no specific mailing list for Perl on VOS. You can post |
| comments to the comp.sys.stratus newsgroup, or use the contact |
| information located in the distribution files on the Stratus |
| Anonymous FTP site. |
| |
| =item * |
| |
| VOS Perl on the web at L<http://ftp.stratus.com/pub/vos/posix/posix.html> |
| |
| =back |
| |
| =head2 EBCDIC Platforms |
| |
| Recent versions of Perl have been ported to platforms such as OS/400 on |
| AS/400 minicomputers as well as OS/390, VM/ESA, and BS2000 for S/390 |
| Mainframes. Such computers use EBCDIC character sets internally (usually |
| Character Code Set ID 0037 for OS/400 and either 1047 or POSIX-BC for S/390 |
| systems). On the mainframe perl currently works under the "Unix system |
| services for OS/390" (formerly known as OpenEdition), VM/ESA OpenEdition, or |
| the BS200 POSIX-BC system (BS2000 is supported in perl 5.6 and greater). |
| See L<perlos390> for details. Note that for OS/400 there is also a port of |
| Perl 5.8.1/5.9.0 or later to the PASE which is ASCII-based (as opposed to |
| ILE which is EBCDIC-based), see L<perlos400>. |
| |
| As of R2.5 of USS for OS/390 and Version 2.3 of VM/ESA these Unix |
| sub-systems do not support the C<#!> shebang trick for script invocation. |
| Hence, on OS/390 and VM/ESA perl scripts can be executed with a header |
| similar to the following simple script: |
| |
| : # use perl |
| eval 'exec /usr/local/bin/perl -S $0 ${1+"$@"}' |
| if 0; |
| #!/usr/local/bin/perl # just a comment really |
| |
| print "Hello from perl!\n"; |
| |
| OS/390 will support the C<#!> shebang trick in release 2.8 and beyond. |
| Calls to C<system> and backticks can use POSIX shell syntax on all |
| S/390 systems. |
| |
| On the AS/400, if PERL5 is in your library list, you may need |
| to wrap your perl scripts in a CL procedure to invoke them like so: |
| |
| BEGIN |
| CALL PGM(PERL5/PERL) PARM('/QOpenSys/hello.pl') |
| ENDPGM |
| |
| This will invoke the perl script F<hello.pl> in the root of the |
| QOpenSys file system. On the AS/400 calls to C<system> or backticks |
| must use CL syntax. |
| |
| On these platforms, bear in mind that the EBCDIC character set may have |
| an effect on what happens with some perl functions (such as C<chr>, |
| C<pack>, C<print>, C<printf>, C<ord>, C<sort>, C<sprintf>, C<unpack>), as |
| well as bit-fiddling with ASCII constants using operators like C<^>, C<&> |
| and C<|>, not to mention dealing with socket interfaces to ASCII computers |
| (see L<"Newlines">). |
| |
| Fortunately, most web servers for the mainframe will correctly |
| translate the C<\n> in the following statement to its ASCII equivalent |
| (C<\r> is the same under both Unix and OS/390 & VM/ESA): |
| |
| print "Content-type: text/html\r\n\r\n"; |
| |
| The values of C<$^O> on some of these platforms includes: |
| |
| uname $^O $Config{'archname'} |
| -------------------------------------------- |
| OS/390 os390 os390 |
| OS400 os400 os400 |
| POSIX-BC posix-bc BS2000-posix-bc |
| VM/ESA vmesa vmesa |
| |
| Some simple tricks for determining if you are running on an EBCDIC |
| platform could include any of the following (perhaps all): |
| |
| if ("\t" eq "\005") { print "EBCDIC may be spoken here!\n"; } |
| |
| if (ord('A') == 193) { print "EBCDIC may be spoken here!\n"; } |
| |
| if (chr(169) eq 'z') { print "EBCDIC may be spoken here!\n"; } |
| |
| One thing you may not want to rely on is the EBCDIC encoding |
| of punctuation characters since these may differ from code page to code |
| page (and once your module or script is rumoured to work with EBCDIC, |
| folks will want it to work with all EBCDIC character sets). |
| |
| Also see: |
| |
| =over 4 |
| |
| =item * |
| |
| L<perlos390>, F<README.os390>, F<perlbs2000>, F<README.vmesa>, |
| L<perlebcdic>. |
| |
| =item * |
| |
| The perl-mvs@perl.org list is for discussion of porting issues as well as |
| general usage issues for all EBCDIC Perls. Send a message body of |
| "subscribe perl-mvs" to majordomo@perl.org. |
| |
| =item * |
| |
| AS/400 Perl information at |
| L<http://as400.rochester.ibm.com/> |
| as well as on CPAN in the F<ports/> directory. |
| |
| =back |
| |
| =head2 Acorn RISC OS |
| |
| Because Acorns use ASCII with newlines (C<\n>) in text files as C<\012> like |
| Unix, and because Unix filename emulation is turned on by default, |
| most simple scripts will probably work "out of the box". The native |
| filesystem is modular, and individual filesystems are free to be |
| case-sensitive or insensitive, and are usually case-preserving. Some |
| native filesystems have name length limits, which file and directory |
| names are silently truncated to fit. Scripts should be aware that the |
| standard filesystem currently has a name length limit of B<10> |
| characters, with up to 77 items in a directory, but other filesystems |
| may not impose such limitations. |
| |
| Native filenames are of the form |
| |
| Filesystem#Special_Field::DiskName.$.Directory.Directory.File |
| |
| where |
| |
| Special_Field is not usually present, but may contain . and $ . |
| Filesystem =~ m|[A-Za-z0-9_]| |
| DsicName =~ m|[A-Za-z0-9_/]| |
| $ represents the root directory |
| . is the path separator |
| @ is the current directory (per filesystem but machine global) |
| ^ is the parent directory |
| Directory and File =~ m|[^\0- "\.\$\%\&:\@\\^\|\177]+| |
| |
| The default filename translation is roughly C<tr|/.|./|;> |
| |
| Note that C<"ADFS::HardDisk.$.File" ne 'ADFS::HardDisk.$.File'> and that |
| the second stage of C<$> interpolation in regular expressions will fall |
| foul of the C<$.> if scripts are not careful. |
| |
| Logical paths specified by system variables containing comma-separated |
| search lists are also allowed; hence C<System:Modules> is a valid |
| filename, and the filesystem will prefix C<Modules> with each section of |
| C<System$Path> until a name is made that points to an object on disk. |
| Writing to a new file C<System:Modules> would be allowed only if |
| C<System$Path> contains a single item list. The filesystem will also |
| expand system variables in filenames if enclosed in angle brackets, so |
| C<< <System$Dir>.Modules >> would look for the file |
| S<C<$ENV{'System$Dir'} . 'Modules'>>. The obvious implication of this is |
| that B<fully qualified filenames can start with C<< <> >>> and should |
| be protected when C<open> is used for input. |
| |
| Because C<.> was in use as a directory separator and filenames could not |
| be assumed to be unique after 10 characters, Acorn implemented the C |
| compiler to strip the trailing C<.c> C<.h> C<.s> and C<.o> suffix from |
| filenames specified in source code and store the respective files in |
| subdirectories named after the suffix. Hence files are translated: |
| |
| foo.h h.foo |
| C:foo.h C:h.foo (logical path variable) |
| sys/os.h sys.h.os (C compiler groks Unix-speak) |
| 10charname.c c.10charname |
| 10charname.o o.10charname |
| 11charname_.c c.11charname (assuming filesystem truncates at 10) |
| |
| The Unix emulation library's translation of filenames to native assumes |
| that this sort of translation is required, and it allows a user-defined list |
| of known suffixes that it will transpose in this fashion. This may |
| seem transparent, but consider that with these rules F<foo/bar/baz.h> |
| and F<foo/bar/h/baz> both map to F<foo.bar.h.baz>, and that C<readdir> and |
| C<glob> cannot and do not attempt to emulate the reverse mapping. Other |
| C<.>'s in filenames are translated to C</>. |
| |
| As implied above, the environment accessed through C<%ENV> is global, and |
| the convention is that program specific environment variables are of the |
| form C<Program$Name>. Each filesystem maintains a current directory, |
| and the current filesystem's current directory is the B<global> current |
| directory. Consequently, sociable programs don't change the current |
| directory but rely on full pathnames, and programs (and Makefiles) cannot |
| assume that they can spawn a child process which can change the current |
| directory without affecting its parent (and everyone else for that |
| matter). |
| |
| Because native operating system filehandles are global and are currently |
| allocated down from 255, with 0 being a reserved value, the Unix emulation |
| library emulates Unix filehandles. Consequently, you can't rely on |
| passing C<STDIN>, C<STDOUT>, or C<STDERR> to your children. |
| |
| The desire of users to express filenames of the form |
| C<< <Foo$Dir>.Bar >> on the command line unquoted causes problems, |
| too: C<``> command output capture has to perform a guessing game. It |
| assumes that a string C<< <[^<>]+\$[^<>]> >> is a |
| reference to an environment variable, whereas anything else involving |
| C<< < >> or C<< > >> is redirection, and generally manages to be 99% |
| right. Of course, the problem remains that scripts cannot rely on any |
| Unix tools being available, or that any tools found have Unix-like command |
| line arguments. |
| |
| Extensions and XS are, in theory, buildable by anyone using free |
| tools. In practice, many don't, as users of the Acorn platform are |
| used to binary distributions. MakeMaker does run, but no available |
| make currently copes with MakeMaker's makefiles; even if and when |
| this should be fixed, the lack of a Unix-like shell will cause |
| problems with makefile rules, especially lines of the form C<cd |
| sdbm && make all>, and anything using quoting. |
| |
| "S<RISC OS>" is the proper name for the operating system, but the value |
| in C<$^O> is "riscos" (because we don't like shouting). |
| |
| =head2 Other perls |
| |
| Perl has been ported to many platforms that do not fit into any of |
| the categories listed above. Some, such as AmigaOS, BeOS, HP MPE/iX, |
| QNX, Plan 9, and VOS, have been well-integrated into the standard |
| Perl source code kit. You may need to see the F<ports/> directory |
| on CPAN for information, and possibly binaries, for the likes of: |
| aos, Atari ST, lynxos, riscos, Novell Netware, Tandem Guardian, |
| I<etc.> (Yes, we know that some of these OSes may fall under the |
| Unix category, but we are not a standards body.) |
| |
| Some approximate operating system names and their C<$^O> values |
| in the "OTHER" category include: |
| |
| OS $^O $Config{'archname'} |
| ------------------------------------------ |
| Amiga DOS amigaos m68k-amigos |
| BeOS beos |
| MPE/iX mpeix PA-RISC1.1 |
| |
| See also: |
| |
| =over 4 |
| |
| =item * |
| |
| Amiga, F<README.amiga> (installed as L<perlamiga>). |
| |
| =item * |
| |
| Be OS, F<README.beos> |
| |
| =item * |
| |
| HP 300 MPE/iX, F<README.mpeix> and Mark Bixby's web page |
| L<http://www.bixby.org/mark/porting.html> |
| |
| =item * |
| |
| A free perl5-based PERL.NLM for Novell Netware is available in |
| precompiled binary and source code form from L<http://www.novell.com/> |
| as well as from CPAN. |
| |
| =item * |
| |
| S<Plan 9>, F<README.plan9> |
| |
| =back |
| |
| =head1 FUNCTION IMPLEMENTATIONS |
| |
| Listed below are functions that are either completely unimplemented |
| or else have been implemented differently on various platforms. |
| Following each description will be, in parentheses, a list of |
| platforms that the description applies to. |
| |
| The list may well be incomplete, or even wrong in some places. When |
| in doubt, consult the platform-specific README files in the Perl |
| source distribution, and any other documentation resources accompanying |
| a given port. |
| |
| Be aware, moreover, that even among Unix-ish systems there are variations. |
| |
| For many functions, you can also query C<%Config>, exported by |
| default from the Config module. For example, to check whether the |
| platform has the C<lstat> call, check C<$Config{d_lstat}>. See |
| L<Config> for a full description of available variables. |
| |
| =head2 Alphabetical Listing of Perl Functions |
| |
| =over 8 |
| |
| =item -X |
| |
| C<-w> only inspects the read-only file attribute (FILE_ATTRIBUTE_READONLY), |
| which determines whether the directory can be deleted, not whether it can |
| be written to. Directories always have read and write access unless denied |
| by discretionary access control lists (DACLs). (S<Win32>) |
| |
| C<-r>, C<-w>, C<-x>, and C<-o> tell whether the file is accessible, |
| which may not reflect UIC-based file protections. (VMS) |
| |
| C<-s> by name on an open file will return the space reserved on disk, |
| rather than the current extent. C<-s> on an open filehandle returns the |
| current size. (S<RISC OS>) |
| |
| C<-R>, C<-W>, C<-X>, C<-O> are indistinguishable from C<-r>, C<-w>, |
| C<-x>, C<-o>. (Win32, VMS, S<RISC OS>) |
| |
| C<-g>, C<-k>, C<-l>, C<-u>, C<-A> are not particularly meaningful. |
| (Win32, VMS, S<RISC OS>) |
| |
| C<-p> is not particularly meaningful. (VMS, S<RISC OS>) |
| |
| C<-d> is true if passed a device spec without an explicit directory. |
| (VMS) |
| |
| C<-x> (or C<-X>) determine if a file ends in one of the executable |
| suffixes. C<-S> is meaningless. (Win32) |
| |
| C<-x> (or C<-X>) determine if a file has an executable file type. |
| (S<RISC OS>) |
| |
| =item alarm |
| |
| Emulated using timers that must be explicitly polled whenever Perl |
| wants to dispatch "safe signals" and therefore cannot interrupt |
| blocking system calls. (Win32) |
| |
| =item atan2 |
| |
| Due to issues with various CPUs, math libraries, compilers, and standards, |
| results for C<atan2()> may vary depending on any combination of the above. |
| Perl attempts to conform to the Open Group/IEEE standards for the results |
| returned from C<atan2()>, but cannot force the issue if the system Perl is |
| run on does not allow it. (Tru64, HP-UX 10.20) |
| |
| The current version of the standards for C<atan2()> is available at |
| L<http://www.opengroup.org/onlinepubs/009695399/functions/atan2.html>. |
| |
| =item binmode |
| |
| Meaningless. (S<RISC OS>) |
| |
| Reopens file and restores pointer; if function fails, underlying |
| filehandle may be closed, or pointer may be in a different position. |
| (VMS) |
| |
| The value returned by C<tell> may be affected after the call, and |
| the filehandle may be flushed. (Win32) |
| |
| =item chmod |
| |
| Only good for changing "owner" read-write access, "group", and "other" |
| bits are meaningless. (Win32) |
| |
| Only good for changing "owner" and "other" read-write access. (S<RISC OS>) |
| |
| Access permissions are mapped onto VOS access-control list changes. (VOS) |
| |
| The actual permissions set depend on the value of the C<CYGWIN> |
| in the SYSTEM environment settings. (Cygwin) |
| |
| =item chown |
| |
| Not implemented. (Win32, S<Plan 9>, S<RISC OS>) |
| |
| Does nothing, but won't fail. (Win32) |
| |
| A little funky, because VOS's notion of ownership is a little funky (VOS). |
| |
| =item chroot |
| |
| Not implemented. (Win32, VMS, S<Plan 9>, S<RISC OS>, VOS, VM/ESA) |
| |
| =item crypt |
| |
| May not be available if library or source was not provided when building |
| perl. (Win32) |
| |
| =item dbmclose |
| |
| Not implemented. (VMS, S<Plan 9>, VOS) |
| |
| =item dbmopen |
| |
| Not implemented. (VMS, S<Plan 9>, VOS) |
| |
| =item dump |
| |
| Not useful. (S<RISC OS>) |
| |
| Not supported. (Cygwin, Win32) |
| |
| Invokes VMS debugger. (VMS) |
| |
| =item exec |
| |
| Implemented via Spawn. (VM/ESA) |
| |
| Does not automatically flush output handles on some platforms. |
| (SunOS, Solaris, HP-UX) |
| |
| Not supported. (Symbian OS) |
| |
| =item exit |
| |
| Emulates Unix exit() (which considers C<exit 1> to indicate an error) by |
| mapping the C<1> to SS$_ABORT (C<44>). This behavior may be overridden |
| with the pragma C<use vmsish 'exit'>. As with the CRTL's exit() |
| function, C<exit 0> is also mapped to an exit status of SS$_NORMAL |
| (C<1>); this mapping cannot be overridden. Any other argument to exit() |
| is used directly as Perl's exit status. On VMS, unless the future |
| POSIX_EXIT mode is enabled, the exit code should always be a valid |
| VMS exit code and not a generic number. When the POSIX_EXIT mode is |
| enabled, a generic number will be encoded in a method compatible with |
| the C library _POSIX_EXIT macro so that it can be decoded by other |
| programs, particularly ones written in C, like the GNV package. (VMS) |
| |
| C<exit()> resets file pointers, which is a problem when called |
| from a child process (created by C<fork()>) in C<BEGIN>. |
| A workaround is to use C<POSIX::_exit>. (Solaris) |
| |
| exit unless $Config{archname} =~ /\bsolaris\b/; |
| require POSIX and POSIX::_exit(0); |
| |
| =item fcntl |
| |
| Not implemented. (Win32) |
| |
| Some functions available based on the version of VMS. (VMS) |
| |
| =item flock |
| |
| Not implemented (VMS, S<RISC OS>, VOS). |
| |
| =item fork |
| |
| Not implemented. (AmigaOS, S<RISC OS>, VM/ESA, VMS) |
| |
| Emulated using multiple interpreters. See L<perlfork>. (Win32) |
| |
| Does not automatically flush output handles on some platforms. |
| (SunOS, Solaris, HP-UX) |
| |
| =item getlogin |
| |
| Not implemented. (S<RISC OS>) |
| |
| =item getpgrp |
| |
| Not implemented. (Win32, VMS, S<RISC OS>) |
| |
| =item getppid |
| |
| Not implemented. (Win32, S<RISC OS>) |
| |
| =item getpriority |
| |
| Not implemented. (Win32, VMS, S<RISC OS>, VOS, VM/ESA) |
| |
| =item getpwnam |
| |
| Not implemented. (Win32) |
| |
| Not useful. (S<RISC OS>) |
| |
| =item getgrnam |
| |
| Not implemented. (Win32, VMS, S<RISC OS>) |
| |
| =item getnetbyname |
| |
| Not implemented. (Win32, S<Plan 9>) |
| |
| =item getpwuid |
| |
| Not implemented. (Win32) |
| |
| Not useful. (S<RISC OS>) |
| |
| =item getgrgid |
| |
| Not implemented. (Win32, VMS, S<RISC OS>) |
| |
| =item getnetbyaddr |
| |
| Not implemented. (Win32, S<Plan 9>) |
| |
| =item getprotobynumber |
| |
| =item getservbyport |
| |
| =item getpwent |
| |
| Not implemented. (Win32, VM/ESA) |
| |
| =item getgrent |
| |
| Not implemented. (Win32, VMS, VM/ESA) |
| |
| =item gethostbyname |
| |
| C<gethostbyname('localhost')> does not work everywhere: you may have |
| to use C<gethostbyname('127.0.0.1')>. (S<Irix 5>) |
| |
| =item gethostent |
| |
| Not implemented. (Win32) |
| |
| =item getnetent |
| |
| Not implemented. (Win32, S<Plan 9>) |
| |
| =item getprotoent |
| |
| Not implemented. (Win32, S<Plan 9>) |
| |
| =item getservent |
| |
| Not implemented. (Win32, S<Plan 9>) |
| |
| =item sethostent |
| |
| Not implemented. (Win32, S<Plan 9>, S<RISC OS>) |
| |
| =item setnetent |
| |
| Not implemented. (Win32, S<Plan 9>, S<RISC OS>) |
| |
| =item setprotoent |
| |
| Not implemented. (Win32, S<Plan 9>, S<RISC OS>) |
| |
| =item setservent |
| |
| Not implemented. (S<Plan 9>, Win32, S<RISC OS>) |
| |
| =item endpwent |
| |
| Not implemented. (MPE/iX, VM/ESA, Win32) |
| |
| =item endgrent |
| |
| Not implemented. (MPE/iX, S<RISC OS>, VM/ESA, VMS, Win32) |
| |
| =item endhostent |
| |
| Not implemented. (Win32) |
| |
| =item endnetent |
| |
| Not implemented. (Win32, S<Plan 9>) |
| |
| =item endprotoent |
| |
| Not implemented. (Win32, S<Plan 9>) |
| |
| =item endservent |
| |
| Not implemented. (S<Plan 9>, Win32) |
| |
| =item getsockopt SOCKET,LEVEL,OPTNAME |
| |
| Not implemented. (S<Plan 9>) |
| |
| =item glob |
| |
| This operator is implemented via the File::Glob extension on most |
| platforms. See L<File::Glob> for portability information. |
| |
| =item gmtime |
| |
| In theory, gmtime() is reliable from -2**63 to 2**63-1. However, |
| because work arounds in the implementation use floating point numbers, |
| it will become inaccurate as the time gets larger. This is a bug and |
| will be fixed in the future. |
| |
| On VOS, time values are 32-bit quantities. |
| |
| =item ioctl FILEHANDLE,FUNCTION,SCALAR |
| |
| Not implemented. (VMS) |
| |
| Available only for socket handles, and it does what the ioctlsocket() call |
| in the Winsock API does. (Win32) |
| |
| Available only for socket handles. (S<RISC OS>) |
| |
| =item kill |
| |
| Not implemented, hence not useful for taint checking. (S<RISC OS>) |
| |
| C<kill()> doesn't have the semantics of C<raise()>, i.e. it doesn't send |
| a signal to the identified process like it does on Unix platforms. |
| Instead C<kill($sig, $pid)> terminates the process identified by $pid, |
| and makes it exit immediately with exit status $sig. As in Unix, if |
| $sig is 0 and the specified process exists, it returns true without |
| actually terminating it. (Win32) |
| |
| C<kill(-9, $pid)> will terminate the process specified by $pid and |
| recursively all child processes owned by it. This is different from |
| the Unix semantics, where the signal will be delivered to all |
| processes in the same process group as the process specified by |
| $pid. (Win32) |
| |
| Is not supported for process identification number of 0 or negative |
| numbers. (VMS) |
| |
| =item link |
| |
| Not implemented. (MPE/iX, S<RISC OS>, VOS) |
| |
| Link count not updated because hard links are not quite that hard |
| (They are sort of half-way between hard and soft links). (AmigaOS) |
| |
| Hard links are implemented on Win32 under NTFS only. They are |
| natively supported on Windows 2000 and later. On Windows NT they |
| are implemented using the Windows POSIX subsystem support and the |
| Perl process will need Administrator or Backup Operator privileges |
| to create hard links. |
| |
| Available on 64 bit OpenVMS 8.2 and later. (VMS) |
| |
| =item localtime |
| |
| localtime() has the same range as L</gmtime>, but because time zone |
| rules change its accuracy for historical and future times may degrade |
| but usually by no more than an hour. |
| |
| =item lstat |
| |
| Not implemented. (S<RISC OS>) |
| |
| Return values (especially for device and inode) may be bogus. (Win32) |
| |
| =item msgctl |
| |
| =item msgget |
| |
| =item msgsnd |
| |
| =item msgrcv |
| |
| Not implemented. (Win32, VMS, S<Plan 9>, S<RISC OS>, VOS) |
| |
| =item open |
| |
| open to C<|-> and C<-|> are unsupported. (Win32, S<RISC OS>) |
| |
| Opening a process does not automatically flush output handles on some |
| platforms. (SunOS, Solaris, HP-UX) |
| |
| =item readlink |
| |
| Not implemented. (Win32, VMS, S<RISC OS>) |
| |
| =item rename |
| |
| Can't move directories between directories on different logical volumes. (Win32) |
| |
| =item rewinddir |
| |
| Will not cause readdir() to re-read the directory stream. The entries |
| already read before the rewinddir() call will just be returned again |
| from a cache buffer. (Win32) |
| |
| =item select |
| |
| Only implemented on sockets. (Win32, VMS) |
| |
| Only reliable on sockets. (S<RISC OS>) |
| |
| Note that the C<select FILEHANDLE> form is generally portable. |
| |
| =item semctl |
| |
| =item semget |
| |
| =item semop |
| |
| Not implemented. (Win32, VMS, S<RISC OS>) |
| |
| =item setgrent |
| |
| Not implemented. (MPE/iX, VMS, Win32, S<RISC OS>) |
| |
| =item setpgrp |
| |
| Not implemented. (Win32, VMS, S<RISC OS>, VOS) |
| |
| =item setpriority |
| |
| Not implemented. (Win32, VMS, S<RISC OS>, VOS) |
| |
| =item setpwent |
| |
| Not implemented. (MPE/iX, Win32, S<RISC OS>) |
| |
| =item setsockopt |
| |
| Not implemented. (S<Plan 9>) |
| |
| =item shmctl |
| |
| =item shmget |
| |
| =item shmread |
| |
| =item shmwrite |
| |
| Not implemented. (Win32, VMS, S<RISC OS>, VOS) |
| |
| =item sockatmark |
| |
| A relatively recent addition to socket functions, may not |
| be implemented even in Unix platforms. |
| |
| =item socketpair |
| |
| Not implemented. (S<RISC OS>, VM/ESA) |
| |
| Available on OpenVOS Release 17.0 or later. (VOS) |
| |
| Available on 64 bit OpenVMS 8.2 and later. (VMS) |
| |
| =item stat |
| |
| Platforms that do not have rdev, blksize, or blocks will return these |
| as '', so numeric comparison or manipulation of these fields may cause |
| 'not numeric' warnings. |
| |
| ctime not supported on UFS (S<Mac OS X>). |
| |
| ctime is creation time instead of inode change time (Win32). |
| |
| device and inode are not meaningful. (Win32) |
| |
| device and inode are not necessarily reliable. (VMS) |
| |
| mtime, atime and ctime all return the last modification time. Device and |
| inode are not necessarily reliable. (S<RISC OS>) |
| |
| dev, rdev, blksize, and blocks are not available. inode is not |
| meaningful and will differ between stat calls on the same file. (os2) |
| |
| some versions of cygwin when doing a stat("foo") and if not finding it |
| may then attempt to stat("foo.exe") (Cygwin) |
| |
| On Win32 stat() needs to open the file to determine the link count |
| and update attributes that may have been changed through hard links. |
| Setting ${^WIN32_SLOPPY_STAT} to a true value speeds up stat() by |
| not performing this operation. (Win32) |
| |
| =item symlink |
| |
| Not implemented. (Win32, S<RISC OS>) |
| |
| Implemented on 64 bit VMS 8.3. VMS requires the symbolic link to be in Unix |
| syntax if it is intended to resolve to a valid path. |
| |
| =item syscall |
| |
| Not implemented. (Win32, VMS, S<RISC OS>, VOS, VM/ESA) |
| |
| =item sysopen |
| |
| The traditional "0", "1", and "2" MODEs are implemented with different |
| numeric values on some systems. The flags exported by C<Fcntl> |
| (O_RDONLY, O_WRONLY, O_RDWR) should work everywhere though. (S<Mac |
| OS>, OS/390, VM/ESA) |
| |
| =item system |
| |
| As an optimization, may not call the command shell specified in |
| C<$ENV{PERL5SHELL}>. C<system(1, @args)> spawns an external |
| process and immediately returns its process designator, without |
| waiting for it to terminate. Return value may be used subsequently |
| in C<wait> or C<waitpid>. Failure to spawn() a subprocess is indicated |
| by setting $? to "255 << 8". C<$?> is set in a way compatible with |
| Unix (i.e. the exitstatus of the subprocess is obtained by "$? >> 8", |
| as described in the documentation). (Win32) |
| |
| There is no shell to process metacharacters, and the native standard is |
| to pass a command line terminated by "\n" "\r" or "\0" to the spawned |
| program. Redirection such as C<< > foo >> is performed (if at all) by |
| the run time library of the spawned program. C<system> I<list> will call |
| the Unix emulation library's C<exec> emulation, which attempts to provide |
| emulation of the stdin, stdout, stderr in force in the parent, providing |
| the child program uses a compatible version of the emulation library. |
| I<scalar> will call the native command line direct and no such emulation |
| of a child Unix program will exists. Mileage B<will> vary. (S<RISC OS>) |
| |
| Does not automatically flush output handles on some platforms. |
| (SunOS, Solaris, HP-UX) |
| |
| The return value is POSIX-like (shifted up by 8 bits), which only allows |
| room for a made-up value derived from the severity bits of the native |
| 32-bit condition code (unless overridden by C<use vmsish 'status'>). |
| If the native condition code is one that has a POSIX value encoded, the |
| POSIX value will be decoded to extract the expected exit value. |
| For more details see L<perlvms/$?>. (VMS) |
| |
| =item times |
| |
| "cumulative" times will be bogus. On anything other than Windows NT |
| or Windows 2000, "system" time will be bogus, and "user" time is |
| actually the time returned by the clock() function in the C runtime |
| library. (Win32) |
| |
| Not useful. (S<RISC OS>) |
| |
| =item truncate |
| |
| Not implemented. (Older versions of VMS) |
| |
| Truncation to same-or-shorter lengths only. (VOS) |
| |
| If a FILEHANDLE is supplied, it must be writable and opened in append |
| mode (i.e., use C<<< open(FH, '>>filename') >>> |
| or C<sysopen(FH,...,O_APPEND|O_RDWR)>. If a filename is supplied, it |
| should not be held open elsewhere. (Win32) |
| |
| =item umask |
| |
| Returns undef where unavailable, as of version 5.005. |
| |
| C<umask> works but the correct permissions are set only when the file |
| is finally closed. (AmigaOS) |
| |
| =item utime |
| |
| Only the modification time is updated. (S<BeOS>, VMS, S<RISC OS>) |
| |
| May not behave as expected. Behavior depends on the C runtime |
| library's implementation of utime(), and the filesystem being |
| used. The FAT filesystem typically does not support an "access |
| time" field, and it may limit timestamps to a granularity of |
| two seconds. (Win32) |
| |
| =item wait |
| |
| =item waitpid |
| |
| Can only be applied to process handles returned for processes spawned |
| using C<system(1, ...)> or pseudo processes created with C<fork()>. (Win32) |
| |
| Not useful. (S<RISC OS>) |
| |
| =back |
| |
| |
| =head1 Supported Platforms |
| |
| The following platforms are known to build Perl 5.12 (as of April 2010, |
| its release date) from the standard source code distribution available |
| at L<http://www.cpan.org/src> |
| |
| =over |
| |
| =item Linux (x86, ARM, IA64) |
| |
| =item HP-UX |
| |
| =item AIX |
| |
| =item Win32 |
| |
| =over |
| |
| =item Windows 2000 |
| |
| =item Windows XP |
| |
| =item Windows Server 2003 |
| |
| =item Windows Vista |
| |
| =item Windows Server 2008 |
| |
| =item Windows 7 |
| |
| =back |
| |
| =item Cygwin |
| |
| =item Solaris (x86, SPARC) |
| |
| =item OpenVMS |
| |
| =over |
| |
| =item Alpha (7.2 and later) |
| |
| =item I64 (8.2 and later) |
| |
| =back |
| |
| =item Symbian |
| |
| =item NetBSD |
| |
| =item FreeBSD |
| |
| =item Debian GNU/kFreeBSD |
| |
| =item Haiku |
| |
| =item Irix (6.5. What else?) |
| |
| =item OpenBSD |
| |
| =item Dragonfly BSD |
| |
| =item QNX Neutrino RTOS (6.5.0) |
| |
| =item MirOS BSD |
| |
| Caveats: |
| |
| =over |
| |
| =item time_t issues that may or may not be fixed |
| |
| =back |
| |
| =item Symbian (Series 60 v3, 3.2 and 5 - what else?) |
| |
| =item Stratus VOS / OpenVOS |
| |
| =item AIX |
| |
| =back |
| |
| =head1 EOL Platforms (Perl 5.14) |
| |
| The following platforms were supported by a previous version of |
| Perl but have been officially removed from Perl's source code |
| as of 5.12: |
| |
| =over |
| |
| =item Atari MiNT |
| |
| =item Apollo Domain/OS |
| |
| =item Apple Mac OS 8/9 |
| |
| =item Tenon Machten |
| |
| =back |
| |
| The following platforms were supported up to 5.10. They may still |
| have worked in 5.12, but supporting code has been removed for 5.14: |
| |
| =over |
| |
| =item Windows 95 |
| |
| =item Windows 98 |
| |
| =item Windows ME |
| |
| =item Windows NT4 |
| |
| =back |
| |
| =head1 Supported Platforms (Perl 5.8) |
| |
| As of July 2002 (the Perl release 5.8.0), the following platforms were |
| able to build Perl from the standard source code distribution |
| available at L<http://www.cpan.org/src/> |
| |
| AIX |
| BeOS |
| BSD/OS (BSDi) |
| Cygwin |
| DG/UX |
| DOS DJGPP 1) |
| DYNIX/ptx |
| EPOC R5 |
| FreeBSD |
| HI-UXMPP (Hitachi) (5.8.0 worked but we didn't know it) |
| HP-UX |
| IRIX |
| Linux |
| Mac OS Classic |
| Mac OS X (Darwin) |
| MPE/iX |
| NetBSD |
| NetWare |
| NonStop-UX |
| ReliantUNIX (formerly SINIX) |
| OpenBSD |
| OpenVMS (formerly VMS) |
| Open UNIX (Unixware) (since Perl 5.8.1/5.9.0) |
| OS/2 |
| OS/400 (using the PASE) (since Perl 5.8.1/5.9.0) |
| PowerUX |
| POSIX-BC (formerly BS2000) |
| QNX |
| Solaris |
| SunOS 4 |
| SUPER-UX (NEC) |
| Tru64 UNIX (formerly DEC OSF/1, Digital UNIX) |
| UNICOS |
| UNICOS/mk |
| UTS |
| VOS |
| Win95/98/ME/2K/XP 2) |
| WinCE |
| z/OS (formerly OS/390) |
| VM/ESA |
| |
| 1) in DOS mode either the DOS or OS/2 ports can be used |
| 2) compilers: Borland, MinGW (GCC), VC6 |
| |
| The following platforms worked with the previous releases (5.6 and |
| 5.7), but we did not manage either to fix or to test these in time |
| for the 5.8.0 release. There is a very good chance that many of these |
| will work fine with the 5.8.0. |
| |
| BSD/OS |
| DomainOS |
| Hurd |
| LynxOS |
| MachTen |
| PowerMAX |
| SCO SV |
| SVR4 |
| Unixware |
| Windows 3.1 |
| |
| Known to be broken for 5.8.0 (but 5.6.1 and 5.7.2 can be used): |
| |
| AmigaOS |
| |
| The following platforms have been known to build Perl from source in |
| the past (5.005_03 and earlier), but we haven't been able to verify |
| their status for the current release, either because the |
| hardware/software platforms are rare or because we don't have an |
| active champion on these platforms--or both. They used to work, |
| though, so go ahead and try compiling them, and let perlbug@perl.org |
| of any trouble. |
| |
| 3b1 |
| A/UX |
| ConvexOS |
| CX/UX |
| DC/OSx |
| DDE SMES |
| DOS EMX |
| Dynix |
| EP/IX |
| ESIX |
| FPS |
| GENIX |
| Greenhills |
| ISC |
| MachTen 68k |
| MPC |
| NEWS-OS |
| NextSTEP |
| OpenSTEP |
| Opus |
| Plan 9 |
| RISC/os |
| SCO ODT/OSR |
| Stellar |
| SVR2 |
| TI1500 |
| TitanOS |
| Ultrix |
| Unisys Dynix |
| |
| The following platforms have their own source code distributions and |
| binaries available via L<http://www.cpan.org/ports/> |
| |
| Perl release |
| |
| OS/400 (ILE) 5.005_02 |
| Tandem Guardian 5.004 |
| |
| The following platforms have only binaries available via |
| L<http://www.cpan.org/ports/index.html> : |
| |
| Perl release |
| |
| Acorn RISCOS 5.005_02 |
| AOS 5.002 |
| LynxOS 5.004_02 |
| |
| Although we do suggest that you always build your own Perl from |
| the source code, both for maximal configurability and for security, |
| in case you are in a hurry you can check |
| L<http://www.cpan.org/ports/index.html> for binary distributions. |
| |
| =head1 SEE ALSO |
| |
| L<perlaix>, L<perlamiga>, L<perlbeos>, L<perlbs2000>, |
| L<perlce>, L<perlcygwin>, L<perldgux>, L<perldos>, L<perlepoc>, |
| L<perlebcdic>, L<perlfreebsd>, L<perlhurd>, L<perlhpux>, L<perlirix>, |
| L<perlmacos>, L<perlmacosx>, L<perlmpeix>, |
| L<perlnetware>, L<perlos2>, L<perlos390>, L<perlos400>, |
| L<perlplan9>, L<perlqnx>, L<perlsolaris>, L<perltru64>, |
| L<perlunicode>, L<perlvmesa>, L<perlvms>, L<perlvos>, |
| L<perlwin32>, and L<Win32>. |
| |
| =head1 AUTHORS / CONTRIBUTORS |
| |
| Abigail <abigail@foad.org>, |
| Charles Bailey <bailey@newman.upenn.edu>, |
| Graham Barr <gbarr@pobox.com>, |
| Tom Christiansen <tchrist@perl.com>, |
| Nicholas Clark <nick@ccl4.org>, |
| Thomas Dorner <Thomas.Dorner@start.de>, |
| Andy Dougherty <doughera@lafayette.edu>, |
| Dominic Dunlop <domo@computer.org>, |
| Neale Ferguson <neale@vma.tabnsw.com.au>, |
| David J. Fiander <davidf@mks.com>, |
| Paul Green <Paul.Green@stratus.com>, |
| M.J.T. Guy <mjtg@cam.ac.uk>, |
| Jarkko Hietaniemi <jhi@iki.fi>, |
| Luther Huffman <lutherh@stratcom.com>, |
| Nick Ing-Simmons <nick@ing-simmons.net>, |
| Andreas J. KE<ouml>nig <a.koenig@mind.de>, |
| Markus Laker <mlaker@contax.co.uk>, |
| Andrew M. Langmead <aml@world.std.com>, |
| Larry Moore <ljmoore@freespace.net>, |
| Paul Moore <Paul.Moore@uk.origin-it.com>, |
| Chris Nandor <pudge@pobox.com>, |
| Matthias Neeracher <neeracher@mac.com>, |
| Philip Newton <pne@cpan.org>, |
| Gary Ng <71564.1743@CompuServe.COM>, |
| Tom Phoenix <rootbeer@teleport.com>, |
| AndrE<eacute> Pirard <A.Pirard@ulg.ac.be>, |
| Peter Prymmer <pvhp@forte.com>, |
| Hugo van der Sanden <hv@crypt0.demon.co.uk>, |
| Gurusamy Sarathy <gsar@activestate.com>, |
| Paul J. Schinder <schinder@pobox.com>, |
| Michael G Schwern <schwern@pobox.com>, |
| Dan Sugalski <dan@sidhe.org>, |
| Nathan Torkington <gnat@frii.com>, |
| John Malmberg <wb8tyw@qsl.net> |