1N/Aperlport - Writing portable Perl
1N/APerl runs on numerous operating systems. While most of them share
1N/Amuch in common, they also have their own unique features.
1N/AThis document is meant to help you to find out what constitutes portable
1N/APerl code. That way once you make a decision to write portably,
1N/Ayou know where the lines are drawn, and you can stay within them.
1N/AThere is a tradeoff between taking full advantage of one particular
1N/Atype of computer and taking advantage of a full range of them.
1N/ANaturally, as you broaden your range and become more diverse, the
1N/Acommon factors drop, and you are left with an increasingly smaller
1N/Aarea of common ground in which you can operate to accomplish a
1N/Aparticular task. Thus, when you begin attacking a problem, it is
1N/Aimportant to consider under which part of the tradeoff curve you
1N/Awant to operate. Specifically, you must decide whether it is
1N/Aimportant that the task that you are coding have the full generality
1N/Aof being portable, or whether to just get the job done right now.
1N/AThis is the hardest choice to be made. The rest is easy, because
1N/APerl provides many choices, whichever way you want to approach your
1N/ALooking at it another way, writing portable code is usually about
1N/Awillfully limiting your available choices. Naturally, it takes
1N/Adiscipline and sacrifice to do that. The product of portability
1N/Aand convenience may be a constant. You have been warned.
1N/ABe aware of two important points:
1N/A=item Not all Perl programs have to be portable
1N/AThere is no reason you should not use Perl as a language to glue Unix
1N/Atools together, or to prototype a Macintosh application, or to manage the
1N/AWindows registry. If it makes no sense to aim for portability for one
1N/Areason or another in a given program, then don't bother.
1N/A=item Nearly all of Perl already I<is> portable
1N/ADon't be fooled into thinking that it is hard to create portable Perl
1N/Acode. It isn't. Perl tries its level-best to bridge the gaps between
1N/Awhat's available on different platforms, and all the means available to
1N/Ause those features. Thus almost all Perl code runs on any machine
1N/Awithout modification. But there are some significant issues in
1N/Awriting portable code, and this document is entirely about those issues.
1N/AHere's the general rule: When you approach a task commonly done
1N/Ausing a whole range of platforms, think about writing portable
1N/Acode. That way, you don't sacrifice much by way of the implementation
1N/Achoices you can avail yourself of, and at the same time you can give
1N/Ayour users lots of platform choices. On the other hand, when you have to
1N/Atake advantage of some unique feature of a particular platform, as is
1N/Aoften the case with systems programming (whether for Unix, Windows,
1N/AS<Mac OS>, VMS, etc.), consider writing platform-specific code.
1N/AWhen the code will run on only two or three operating systems, you
1N/Amay need to consider only the differences of those particular systems.
1N/AThe important thing is to decide where the code will run and to be
1N/Adeliberate in your decision.
1N/AThe material below is separated into three main sections: main issues of
1N/Aportability (L<"ISSUES">, platform-specific issues (L<"PLATFORMS">, and
1N/Abuilt-in perl functions that behave differently on various ports
1N/A(L<"FUNCTION IMPLEMENTATIONS">.
1N/AThis information should not be considered complete; it includes possibly
1N/Atransient information about idiosyncrasies of some of the ports, almost
1N/Aall of which are in a state of constant evolution. Thus, this material
1N/Ashould be considered a perpetual work in progress
1N/AIn most operating systems, lines in files are terminated by newlines.
1N/AJust what is used as a newline may vary from OS to OS. Unix
1N/Atraditionally uses C<\012>, one type of DOSish I/O uses C<\015\012>,
1N/Aand S<Mac OS> uses C<\015>.
1N/APerl uses C<\n> to represent the "logical" newline, where what is
1N/Alogical may depend on the platform in use. In MacPerl, C<\n> always
1N/Ameans C<\015>. In DOSish perls, C<\n> usually means C<\012>, but
1N/Awhen accessing a file in "text" mode, STDIO translates it to (or
1N/Afrom) C<\015\012>, depending on whether you're reading or writing.
1N/AUnix does the same thing on ttys in canonical mode. C<\015\012>
1N/Ais commonly referred to as CRLF.
1N/AA common cause of unportable programs is the misuse of chop() to trim
1N/A @array = split(/:/);
1N/AYou can get away with this on Unix and Mac OS (they have a single
1N/Acharacter end-of-line), but the same program will break under DOSish
1N/Aperls because you're only chop()ing half the end-of-line. Instead,
1N/Achomp() should be used to trim newlines. The Dunce::Files module can
1N/Ahelp audit your code for misuses of chop().
1N/AWhen dealing with binary files (or text files in binary mode) be sure
1N/Ato explicitly set $/ to the appropriate value for your file format
1N/Abefore using chomp().
1N/ABecause of the "text" mode translation, DOSish perls have limitations
1N/Ain using C<seek> and C<tell> on a file accessed in "text" mode.
1N/AStick to C<seek>-ing to locations you got from C<tell> (and no
1N/Aothers), and you are usually free to use C<seek> and C<tell> even
1N/Ain "text" mode. Using C<seek> or C<tell> or other file operations
1N/Amay be non-portable. If you use C<binmode> on a file, however, you
1N/Acan usually C<seek> and C<tell> with arbitrary values in safety.
1N/AA common misconception in socket programming is that C<\n> eq C<\012>
1N/Aeverywhere. When using protocols such as common Internet protocols,
1N/AC<\012> and C<\015> are called for specifically, and the values of
1N/Athe logical C<\n> and C<\r> (carriage return) are not reliable.
1N/A print SOCKET "Hi there, client!\r\n"; # WRONG
1N/A print SOCKET "Hi there, client!\015\012"; # RIGHT
1N/AHowever, using C<\015\012> (or C<\cM\cJ>, or C<\x0D\x0A>) can be tedious
1N/Aand unsightly, as well as confusing to those maintaining the code. As
1N/Asuch, the Socket module supplies the Right Thing for those who want it.
1N/A use Socket qw(:DEFAULT :crlf);
1N/A print SOCKET "Hi there, client!$CRLF" # RIGHT
1N/AWhen reading from a socket, remember that the default input record
1N/Aseparator C<$/> is C<\n>, but robust socket code will recognize as
1N/Aeither C<\012> or C<\015\012> as end of line:
1N/ABecause both CRLF and LF end in LF, the input record separator can
1N/Abe set to LF and any CR stripped later. Better to write:
1N/A use Socket qw(:DEFAULT :crlf);
1N/A local($/) = LF; # not needed if $/ is already \012
1N/A s/$CR?$LF/\n/; # not sure if socket uses LF or CRLF, OK
1N/A # s/\015?\012/\n/; # same thing
1N/AThis example is preferred over the previous one--even for Unix
1N/Aplatforms--because now any C<\015>'s (C<\cM>'s) are stripped out
1N/A(and there was much rejoicing).
1N/ASimilarly, functions that return text data--such as a function that
1N/Afetches a web page--should sometimes translate newlines before
1N/Areturning the data, if they've not yet been translated to the local
1N/Anewline representation. A single line of code will often suffice:
1N/A $data =~ s/\015?\012/\n/g;
1N/ASome of this may be confusing. Here's a handy reference to the ASCII CR
1N/Aand LF characters. You can print it out and stick it in your wallet.
1N/A LF eq \012 eq \x0A eq \cJ eq chr(10) eq ASCII 10
1N/A CR eq \015 eq \x0D eq \cM eq chr(13) eq ASCII 13
1N/A | Unix | DOS | Mac |
1N/A ---------------------------
1N/A \n * | LF | CRLF | CR |
1N/A \r * | CR | CR | LF |
1N/A ---------------------------
1N/AThe Unix column assumes that you are not accessing a serial line
1N/A(like a tty) in canonical mode. If you are, then CR on input becomes
1N/A"\n", and "\n" on output becomes CRLF.
1N/AThese are just the most common definitions of C<\n> and C<\r> in Perl.
1N/AThere may well be others. For example, on an EBCDIC implementation
1N/Asuch as
z/OS (OS/390) or OS/400 (using the ILE, the PASE is ASCII-based)
1N/Athe above material is similar to "Unix" but the code numbers change:
1N/A LF eq \025 eq \x15 eq \cU eq chr(21) eq CP-1047 21
1N/A LF eq \045 eq \x25 eq chr(37) eq CP-0037 37
1N/A CR eq \015 eq \x0D eq \cM eq chr(13) eq CP-1047 13
1N/A CR eq \015 eq \x0D eq \cM eq chr(13) eq CP-0037 13
1N/A ----------------------
1N/A ----------------------
1N/A=head2 Numbers endianness and Width
1N/ADifferent CPUs store integers and floating point numbers in different
1N/Aorders (called I<endianness>) and widths (32-bit and 64-bit being the
1N/Amost common today). This affects your programs when they attempt to transfer
1N/Anumbers in binary format from one CPU architecture to another,
1N/Ausually either "live" via network connection, or by storing the
1N/Anumbers to secondary storage such as a disk file or tape.
1N/AConflicting storage orders make utter mess out of the numbers. If a
1N/Alittle-endian host (Intel, VAX) stores 0x12345678 (305419896 in
1N/Adecimal), a big-endian host (Motorola, Sparc, PA) reads it as
1N/A0x78563412 (2018915346 in decimal). Alpha and MIPS can be either:
1N/Athem in big-endian mode. To avoid this problem in network (socket)
1N/Aconnections use the C<pack> and C<unpack> formats C<n> and C<N>, the
1N/A"network" orders. These are guaranteed to be portable.
1N/AYou can explore the endianness of your platform by unpacking a
1N/Adata structure packed in native format such as:
1N/A print unpack("h*", pack("s2", 1, 2)), "\n";
1N/A # '10002000' on
e.g. Intel x86 or Alpha 21064 in little-endian mode
1N/A # '00100020' on
e.g. Motorola 68040
1N/AIf you need to distinguish between endian architectures you could use
1N/Aeither of the variables set like so:
1N/A $is_big_endian = unpack("h*", pack("s", 1)) =~ /01/;
1N/A $is_little_endian = unpack("h*", pack("s", 1)) =~ /^1/;
1N/ADiffering widths can cause truncation even between platforms of equal
1N/Aendianness. The platform of shorter width loses the upper parts of the
1N/Anumber. There is no good solution for this problem except to avoid
1N/Atransferring or storing raw binary numbers.
1N/AOne can circumnavigate both these problems in two ways. Either
1N/Atransfer and store numbers always in text format, instead of raw
1N/Abinary, or else consider using modules like Data::Dumper (included in
1N/Athe standard distribution as of Perl 5.005) and Storable (included as
1N/Aof perl 5.8). Keeping all data as text significantly simplifies matters.
1N/AThe v-strings are portable only up to v2147483647 (0x7FFFFFFF), that's
1N/Ahow far EBCDIC, or more precisely UTF-EBCDIC will go.
1N/A=head2 Files and Filesystems
1N/AMost platforms these days structure files in a hierarchical fashion.
1N/ASo, it is reasonably safe to assume that all platforms support the
1N/Anotion of a "path" to uniquely identify a file on the system. How
1N/Athat path is really written, though, differs considerably.
1N/AAlthough similar, file path specifications differ between Unix,
1N/AWindows, S<Mac OS>, OS/2, VMS, VOS, S<RISC OS>, and probably others.
1N/AUnix, for example, is one of the few OSes that has the elegant idea
1N/Aof a single root directory.
1N/ADOS, OS/2, VMS, VOS, and Windows can work similarly to Unix with C</>
1N/Aas path separator, or in their own idiosyncratic ways (such as having
1N/Aseveral root directories and various "unrooted" device files such NIL:
1N/AS<Mac OS> uses C<:> as a path separator instead of C</>.
1N/AThe filesystem may support neither hard links (C<link>) nor
1N/Asymbolic links (C<symlink>, C<readlink>, C<lstat>).
1N/AThe filesystem may support neither access timestamp nor change
1N/Atimestamp (meaning that about the only portable timestamp is the
1N/Amodification timestamp), or one second granularity of any timestamps
1N/A(
e.g. the FAT filesystem limits the time granularity to two seconds).
1N/AThe "inode change timestamp" (the C<-C> filetest) may really be the
1N/A"creation timestamp" (which it is not in UNIX).
1N/AVOS perl can emulate Unix filenames with C</> as path separator. The
1N/Anative pathname characters greater-than, less-than, number-sign, and
1N/Apercent-sign are always accepted.
1N/AS<RISC OS> perl can emulate Unix filenames with C</> as path
1N/Aseparator, or go native and use C<.> for path separator and C<:> to
1N/Asignal filesystems and disk names.
1N/ADon't assume UNIX filesystem access semantics: that read, write,
1N/Aand execute are all the permissions there are, and even if they exist,
1N/Athat their semantics (for example what do r, w, and x mean on
1N/Aa directory) are the UNIX ones. The various
UNIX/POSIX compatibility
1N/Alayers usually try to make interfaces like chmod() work, but sometimes
1N/Athere simply is no good mapping.
1N/AIf all this is intimidating, have no (well, maybe only a little)
1N/Afear. There are modules that can help. The File::Spec modules
1N/Aprovide methods to do the Right Thing on whatever platform happens
1N/Ato be running the program.
1N/A use File::Spec::Functions;
1N/A chdir(updir()); # go up one directory
1N/AFile::Spec is available in the standard distribution as of version
1N/A5.004_05. File::Spec::Functions is only in File::Spec 0.7 and later,
1N/Aand some versions of perl come with version 0.6. If File::Spec
1N/Ais not updated to 0.7 or later, you must use the object-oriented
1N/Ainterface from File::Spec (or upgrade File::Spec).
1N/AIn general, production code should not have file paths hardcoded.
1N/AMaking them user-supplied or read from a configuration file is
1N/Abetter, keeping in mind that file path syntax varies on different
1N/AThis is especially noticeable in scripts like Makefiles and test suites,
1N/Awhich often assume C</> as a path separator for subdirectories.
1N/AAlso of use is File::Basename from the standard distribution, which
1N/Asplits a pathname into pieces (base filename, full path to directory,
1N/AEven when on a single platform (if you can call Unix a single platform),
1N/Aremember not to count on the existence or the contents of particular
1N/Apasswords, because the system is using some form of enhanced security.
1N/AOr it may not contain all the accounts, because the system is using NIS.
1N/AIf code does need to rely on such a file, include a description of the
1N/Afile and its format in the code's documentation, then make it easy for
1N/Athe user to override the default location of the file.
1N/ADon't assume a text file will end with a newline. They should,
1N/ADo not have two files or directories of the same name with different
1N/Acase-insensitive (or at least case-forgiving) filenames. Also, try
1N/Anot to have non-word characters (except for C<.>) in the names, and
1N/Akeep them to the 8.3 convention, for maximum portability, onerous a
1N/Aburden though this may appear.
1N/ALikewise, when using the AutoSplit module, try to keep your functions to
1N/A8.3 naming and case-insensitive conventions; or, at the least,
1N/Amake it so the resulting files have a unique (case-insensitively)
1N/AWhitespace in filenames is tolerated on most systems, but not all,
1N/Aand even on systems where it might be tolerated, some utilities
1N/Amight become confused by such whitespace.
1N/AMany systems (DOS, VMS) cannot have more than one C<.> in their filenames.
1N/ADon't assume C<< > >> won't be the first character of a filename.
1N/AAlways use C<< < >> explicitly to open a file for reading, or even
1N/Abetter, use the three-arg version of open, unless you want the user to
1N/Abe able to specify a pipe open.
1N/A open(FILE, '<', $existing_file) or die $!;
1N/AIf filenames might use strange characters, it is safest to open it
1N/Awith C<sysopen> instead of C<open>. C<open> is magic and can
1N/Atranslate characters like C<< > >>, C<< < >>, and C<|>, which may
1N/Abe the wrong thing to do. (Sometimes, though, it's the right thing.)
1N/AThree-arg open can also help protect against this translation in cases
1N/Awhere it is undesirable.
1N/ADon't use C<:> as a part of a filename since many systems use that for
1N/Atheir own semantics (Mac OS Classic for separating pathname components,
1N/Amany networking schemes and utilities for separating the nodename and
1N/Athe pathname, and so on). For the same reasons, avoid C<@>, C<;> and
1N/ADon't assume that in pathnames you can collapse two leading slashes
1N/AC<//> into one: some networking and clustering filesystems have special
1N/Asemantics for that. Let the operating system to sort it out.
1N/AThe I<portable filename characters> as defined by ANSI C are
1N/A 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
1N/A 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
1N/Aand the "-" shouldn't be the first character. If you want to be
1N/Ahypercorrect, stay case-insensitive and within the 8.3 naming
1N/Aconvention (all the files and directories have to be unique within one
1N/Adirectory if their names are lowercased and truncated to eight
1N/Acharacters before the C<.>, if any, and to three characters after the
1N/AC<.>, if any). (And do not use C<.>s in directory names.)
1N/A=head2 System Interaction
1N/ANot all platforms provide a command line. These are usually platforms
1N/Athat rely primarily on a Graphical User Interface (GUI) for user
1N/Ainteraction. A program requiring a command line interface might
1N/Anot work everywhere. This is probably for the user of the program
1N/Ato deal with, so don't stay up late worrying about it.
1N/ASome platforms can't delete or rename files held open by the system,
1N/Athis limitation may also apply to changing filesystem metainformation
1N/Alike file permissions or owners. Remember to C<close> files when you
1N/Aare done with them. Don't C<unlink> or C<rename> an open file. Don't
1N/AC<tie> or C<open> a file already tied or opened; C<untie> or C<close>
1N/ADon't open the same file more than once at a time for writing, as some
1N/Aoperating systems put mandatory locks on such files.
1N/Afilesystems (AFS, DFS) the permission to
add/delete directory entries
1N/Ais a completely separate permission.
1N/ADon't assume that a single C<unlink> completely gets rid of the file:
1N/Asome filesystems (most notably the ones in VMS) have versioned
1N/Afilesystems, and unlink() removes only the most recent one (it doesn't
1N/Aremove all the versions because by default the native tools on those
1N/Aplatforms remove just the most recent version, too). The portable
1N/Aidiom to remove all the versions of a file is
1N/A 1 while unlink "file";
1N/AThis will terminate if the file is undeleteable for some reason
1N/A(protected, not there, and so on).
1N/ADon't count on a specific environment variable existing in C<%ENV>.
1N/ADon't count on C<%ENV> entries being case-sensitive, or even
1N/Acase-preserving. Don't try to clear %ENV by saying C<%ENV = ();>, or,
1N/Aif you really have to, make it conditional on C<$^O ne 'VMS'> since in
1N/AVMS the C<%ENV> table is much more than a per-process key-value string
1N/ADon't count on signals or C<%SIG> for anything.
1N/ADon't count on filename globbing. Use C<opendir>, C<readdir>, and
1N/ADon't count on per-program environment variables, or per-program current
1N/ADon't count on specific values of C<$!>, neither numeric nor
1N/Aespecially the strings values-- users may switch their locales causing
1N/Aerror messages to be translated into their languages. If you can
1N/Atrust a POSIXish environment, you can portably use the symbols defined
1N/Aby the Errno module, like ENOENT. And don't trust on the values of C<$!>
1N/Aat all except immediately after a failed system call.
1N/A=head2 Command names versus file pathnames
1N/ADon't assume that the name used to invoke a command or program with
1N/AC<system> or C<exec> can also be used to test for the existence of the
1N/Afile that holds the executable code for that command or program.
1N/AFirst, many systems have "internal" commands that are built-in to the
1N/Ashell or OS and while these commands can be invoked, there is no
1N/Acorresponding file. Second, some operating systems (
e.g., Cygwin,
1N/ADJGPP, OS/2, and VOS) have required suffixes for executable files;
1N/Athese suffixes are generally permitted on the command name but are not
1N/Arequired. Thus, a command like "perl" might exist in a file named
1N/AThe variable "_exe" in the Config module holds the executable suffix,
1N/Aif any. Third, the VMS port carefully sets up $^X and
1N/A$Config{perlpath} so that no further processing is required. This is
1N/Ajust as well, because the matching regular expression used below would
1N/Athen have to deal with a possible trailing version number in the VMS
1N/ATo convert $^X to a file pathname, taking account of the requirements
1N/Aof the various operating system possibilities, say:
1N/A {$thisperl .= $Config{_exe} unless $thisperl =~ m/$Config{_exe}$/i;}
1N/ATo convert $Config{perlpath} to a file pathname, say:
1N/A $thisperl = $Config{perlpath};
1N/A {$thisperl .= $Config{_exe} unless $thisperl =~ m/$Config{_exe}$/i;}
1N/ADon't assume that you can reach the public Internet.
1N/ADon't assume that there is only one way to get through firewalls
1N/Ato the public Internet.
1N/ADon't assume that you can reach outside world through any other port
1N/Athan 80, or some web proxy. ftp is blocked by many firewalls.
1N/ADon't assume that you can send email by connecting to the local SMTP port.
1N/ADon't assume that you can reach yourself or any node by the name
1N/A'localhost'. The same goes for '127.0.0.1'. You will have to try both.
1N/ADon't assume that the host has only one network card, or that it
1N/Acan't bind to many virtual IP addresses.
1N/ADon't assume a particular network device name.
1N/ADon't assume a particular set of ioctl()s will work.
1N/ADon't assume that you can ping hosts and get replies.
1N/ADon't assume that any particular port (service) will respond.
1N/ADon't assume that Sys::Hostname() (or any other API or command)
1N/Areturns either a fully qualified hostname or a non-qualified hostname:
1N/Ait all depends on how the system had been configured. Also remember
1N/Athings like DHCP and NAT-- the hostname you get back might not be very
1N/AAll the above "don't":s may look daunting, and they are -- but the key
1N/Ais to degrade gracefully if one cannot reach the particular network
1N/Aservice one wants. Croaking or hanging do not look very professional.
1N/A=head2 Interprocess Communication (IPC)
1N/AIn general, don't directly access the system in code meant to be
1N/Aportable. That means, no C<system>, C<exec>, C<fork>, C<pipe>,
1N/AC<``>, C<qx//>, C<open> with a C<|>, nor any of the other things
1N/Athat makes being a perl hacker worth being.
1N/ACommands that launch external processes are generally supported on
1N/Amost platforms (though many of them do not support any type of
1N/Aforking). The problem with using them arises from what you invoke
1N/Athem on. External tools are often named differently on different
1N/Aplatforms, may not be available in the same location, might accept
1N/Adifferent arguments, can behave differently, and often present their
1N/Aresults in a platform-dependent way. Thus, you should seldom depend
1N/Aon them to produce consistent results. (Then again, if you're calling
1N/AI<netstat -a>, you probably don't expect it to run on both Unix and CP/M.)
1N/AOne especially common bit of Perl code is opening a pipe to B<sendmail>:
1N/A or die "cannot fork sendmail: $!";
1N/AThis is fine for systems programming when sendmail is known to be
1N/Aavailable. But it is not fine for many non-Unix systems, and even
1N/Asome Unix systems that may not have sendmail installed. If a portable
1N/Asolution is needed, see the various distributions on CPAN that deal
1N/Awith it. Mail::Mailer and Mail::Send in the MailTools distribution are
1N/Acommonly used, and provide several mailing methods, including mail,
1N/Asendmail, and direct SMTP (via Net::SMTP) if a mail transfer agent is
1N/Anot available. Mail::Sendmail is a standalone module that provides
1N/Asimple, platform-independent mailing.
1N/AThe Unix System V IPC (C<msg*(), sem*(), shm*()>) is not available
1N/Aeven on all Unix platforms.
1N/ADo not use either the bare result of C<pack("N", 10, 20, 30, 40)> or
1N/Abare v-strings (such as C<v10.20.30.40>) to represent IPv4 addresses:
1N/Aboth forms just pack the four bytes into network order. That this
1N/Awould be equal to the C language C<in_addr> struct (which is what the
1N/Asocket code internally uses) is not guaranteed. To be portable use
1N/Athe routines of the Socket extension, such as C<inet_aton()>,
1N/AC<inet_ntoa()>, and C<sockaddr_in()>.
1N/AThe rule of thumb for portable code is: Do it all in portable Perl, or
1N/Ause a module (that may internally implement it with platform-specific
1N/Acode, but expose a common interface).
1N/A=head2 External Subroutines (XS)
1N/AXS code can usually be made to work with any platform, but dependent
1N/Alibraries, header files, etc., might not be readily available or
1N/Aportable, or the XS code itself might be platform-specific, just as Perl
1N/Acode might be. If the libraries and headers are portable, then it is
1N/Anormally reasonable to make sure the XS code is portable, too.
1N/AA different type of portability issue arises when writing XS code:
1N/Aavailability of a C compiler on the end-user's system. C brings
1N/Awith it its own portability issues, and writing XS code will expose
1N/Ayou to some of those. Writing purely in Perl is an easier way to
1N/A=head2 Standard Modules
1N/AIn general, the standard modules work across platforms. Notable
1N/Aexceptions are the CPAN module (which currently makes connections to external
1N/Aprograms that may not be available), platform-specific modules (like
1N/AExtUtils::MM_VMS), and DBM modules.
1N/AThere is no one DBM module available on all platforms.
1N/ASDBM_File and the others are generally available on all Unix and DOSish
1N/Aports, but not in MacPerl, where only NBDM_File and DB_File are
1N/AThe good news is that at least some DBM module should be available, and
1N/AAnyDBM_File will use whichever module it can find. Of course, then
1N/Athe code needs to be fairly strict, dropping to the greatest common
1N/Afactor (
e.g., not exceeding 1K for each record), so that it will
1N/Awork with any DBM module. See L<AnyDBM_File> for more details.
1N/AThe system's notion of time of day and calendar date is controlled in
1N/Awidely different ways. Don't assume the timezone is stored in C<$ENV{TZ}>,
1N/Aand even if it is, don't assume that you can control the timezone through
1N/Athat variable. Don't assume anything about the three-letter timezone
1N/Aabbreviations (for example that MST would be the Mountain Standard Time,
1N/Ait's been known to stand for Moscow Standard Time). If you need to
1N/Ause timezones, express them in some unambiguous format like the
1N/Aexact number of minutes offset from UTC, or the POSIX timezone
1N/ADon't assume that the epoch starts at 00:00:00, January 1, 1970,
1N/Abecause that is OS- and implementation-specific. It is better to
1N/Astore a date in an unambiguous representation. The ISO 8601 standard
1N/Adefines YYYY-MM-DD as the date format, or YYYY-MM-DDTHH-MM-SS
1N/A(that's a literal "T" separating the date from the time).
1N/APlease do use the ISO 8601 instead of making us to guess what
1N/Adate 02/03/04 might be. ISO 8601 even sorts nicely as-is.
1N/AA text representation (like "1987-12-18") can be easily converted
1N/Ainto an OS-specific value using a module like Date::Parse.
1N/AAn array of values, such as those returned by C<localtime>, can be
1N/Aconverted to an OS-specific representation using Time::Local.
1N/AWhen calculating specific times, such as for tests in time or date modules,
1N/Ait may be appropriate to calculate an offset for the epoch.
1N/A require Time::Local;
1N/A $offset = Time::Local::timegm(0, 0, 0, 1, 0, 70);
1N/AThe value for C<$offset> in Unix will be C<0>, but in Mac OS will be
1N/Asome large number. C<$offset> can then be added to a Unix time value
1N/Ato get what should be the proper value on any system.
1N/AOn Windows (at least), you shouldn't pass a negative value to C<gmtime> or
1N/A=head2 Character sets and character encoding
1N/AAssume very little about character sets.
1N/AAssume nothing about numerical values (C<ord>, C<chr>) of characters.
1N/ADo not use explicit code point ranges (like \xHH-\xHH); use for
1N/Aexample symbolic character classes like C<[:print:]>.
1N/ADo not assume that the alphabetic characters are encoded contiguously
1N/A(in the numeric sense). There may be gaps.
1N/ADo not assume anything about the ordering of the characters.
1N/AThe lowercase letters may come before or after the uppercase letters;
1N/Athe lowercase and uppercase may be interlaced so that both `a' and `A'
1N/Acome before `b'; the accented and other international characters may
1N/Abe interlaced so that E<auml> comes before `b'.
1N/A=head2 Internationalisation
1N/AIf you may assume POSIX (a rather large assumption), you may read
1N/Amore about the POSIX locale system from L<perllocale>. The locale
1N/Asystem at least attempts to make things a little bit more portable,
1N/Aor at least more convenient and native-friendly for non-English
1N/Ausers. The system affects character sets and encoding, and date
1N/Aand time formatting--amongst other things.
1N/AIf you really want to be international, you should consider Unicode.
1N/ASee L<perluniintro> and L<perlunicode> for more information.
1N/AIf you want to use non-ASCII bytes (outside the bytes 0x00..0x7f) in
1N/Athe "source code" of your code, to be portable you have to be explicit
1N/Aabout what bytes they are. Someone might for example be using your
1N/Acode under a UTF-8 locale, in which case random native bytes might be
1N/Aillegal ("Malformed UTF-8 ...") This means that for example embedding
1N/AISO 8859-1 bytes beyond 0x7f into your strings might cause trouble
1N/Alater. If the bytes are native 8-bit bytes, you can use the C<bytes>
1N/Apragma. If the bytes are in a string (regular expression being a
1N/Acurious string), you can often also use the C<\xHH> notation instead
1N/Aof embedding the bytes as-is. If they are in some particular legacy
1N/Aencoding (ether single-byte or something more complicated), you can
1N/Ause the C<encoding> pragma. (If you want to write your code in UTF-8,
1N/Ayou can use either the C<utf8> pragma, or the C<encoding> pragma.)
1N/AThe C<bytes> and C<utf8> pragmata are available since Perl 5.6.0, and
1N/Athe C<encoding> pragma since Perl 5.8.0.
1N/A=head2 System Resources
1N/AIf your code is destined for systems with severely constrained (or
1N/Amissing!) virtual memory systems then you want to be I<especially> mindful
1N/Aof avoiding wasteful constructs such as:
1N/A # NOTE: this is no longer "bad" in perl5.005
1N/A for (0..10000000) {} # bad
1N/A for (my $x = 0; $x <= 10000000; ++$x) {} # good
1N/A @lines = <VERY_LARGE_FILE>; # bad
1N/A while (<FILE>) {$file .= $_} # sometimes bad
1N/A $file = join('', <FILE>); # better
1N/AThe last two constructs may appear unintuitive to most people. The
1N/Afirst repeatedly grows a string, whereas the second allocates a
1N/Alarge chunk of memory in one go. On some systems, the second is
1N/Amore efficient that the first.
1N/AMost multi-user platforms provide basic levels of security, usually
1N/Aimplemented at the filesystem level. Some, however, do
1N/Anot-- unfortunately. Thus the notion of user id, or "home" directory,
1N/Aor even the state of being logged-in, may be unrecognizable on many
1N/Aplatforms. If you write programs that are security-conscious, it
1N/Ais usually best to know what type of system you will be running
1N/Aunder so that you can write code explicitly for that platform (or
1N/ADon't assume the UNIX filesystem access semantics: the operating
1N/Asystem or the filesystem may be using some ACL systems, which are
1N/Aricher languages than the usual rwx. Even if the rwx exist,
1N/Atheir semantics might be different.
1N/A(From security viewpoint testing for permissions before attempting to
1N/Ado something is silly anyway: if one tries this, there is potential
1N/Afor race conditions-- someone or something might change the
1N/Apermissions between the permissions check and the actual operation.
1N/AJust try the operation.)
1N/ADon't assume the UNIX user and group semantics: especially, don't
1N/Aexpect the C<< $< >> and C<< $> >> (or the C<$(> and C<$)>) to work
1N/Afor switching identities (or memberships).
1N/ADon't assume set-uid and set-gid semantics. (And even if you do,
1N/Athink twice: set-uid and set-gid are a known can of security worms.)
1N/AFor those times when it is necessary to have platform-specific code,
1N/Aconsider keeping the platform-specific code in one place, making porting
1N/Ato other platforms easier. Use the Config module and the special
1N/Avariable C<$^O> to differentiate platforms, as described in
1N/ABe careful in the tests you supply with your module or programs.
1N/AModule code may be fully portable, but its tests might not be. This
1N/Aoften happens when tests spawn off other processes or call external
1N/Aprograms to aid in the testing, or when (as noted above) the tests
1N/Aassume certain things about the filesystem and paths. Be careful not
1N/Ato depend on a specific output style for errors, such as when checking
1N/AC<$!> after a failed system call. Using C<$!> for anything else than
1N/Adisplaying it as output is doubtful (though see the Errno module for
1N/Atesting reasonably portably for error value). Some platforms expect
1N/Aa certain output format, and Perl on those platforms may have been
1N/Aadjusted accordingly. Most specifically, don't anchor a regex when
1N/Atesting an error value.
1N/AModules uploaded to CPAN are tested by a variety of volunteers on
1N/Adifferent platforms. These CPAN testers are notified by mail of each
1N/Anew upload, and reply to the list with PASS, FAIL, NA (not applicable to
1N/Athis platform), or UNKNOWN (unknown), along with any relevant notations.
1N/AThe purpose of the testing is twofold: one, to help developers fix any
1N/Aproblems in their code that crop up because of lack of testing on other
1N/Aplatforms; two, to provide users with information about whether
1N/Aa given module works on a given platform.
1N/A=item Mailing list: cpan-testers@perl.org
1N/AAs of version 5.002, Perl is built with a C<$^O> variable that
1N/Aindicates the operating system it was built on. This was implemented
1N/Ato help speed up code that would otherwise have to C<use Config>
1N/Aand use the value of C<$Config{osname}>. Of course, to get more
1N/Adetailed information about the system, looking into C<%Config> is
1N/Acertainly recommended.
1N/AC<%Config> cannot always be trusted, however, because it was built
1N/Aat compile time. If perl was built in one place, then transferred
1N/Aelsewhere, some values may be wrong. The values may even have been
1N/Aedited after the fact.
1N/APerl works on a bewildering variety of Unix and Unix-like platforms (see
1N/Ae.g. most of the files in the F<hints/> directory in the source code kit).
1N/AOn most of these systems, the value of C<$^O> (hence C<$Config{'osname'}>,
1N/Atoo) is determined either by lowercasing and stripping punctuation from the
1N/Afirst field of the string returned by typing C<uname -a> (or a similar command)
1N/Aat the shell prompt or by testing the file system for the presence of
1N/Auniquely named files such as a kernel or header file. Here, for example,
1N/Aare a few of the more popular Unix flavors:
1N/A uname $^O $Config{'archname'}
1N/A --------------------------------------------
1N/A Darwin darwin darwin
1N/A dgux dgux AViiON-dgux
1N/A FreeBSD freebsd freebsd-i386
1N/A Linux linux arm-linux
1N/A Linux linux i386-linux
1N/A Linux linux i586-linux
1N/A Linux linux ppc-linux
1N/A HP-UX hpux PA-RISC1.1
1N/A Mac OS X darwin darwin
1N/A MachTen PPC machten powerpc-machten
1N/A NeXT 3 next next-fat
1N/A NeXT 4 next OPENSTEP-Mach
1N/A openbsd openbsd i386-openbsd
1N/A OSF1 dec_osf alpha-dec_osf
1N/A reliantunix-n svr4 RM400-svr4
1N/A SCO_SV sco_sv i386-sco_sv
1N/A SINIX-N svr4 RM400-svr4
1N/A sn4609 unicos CRAY_C90-unicos
1N/A sn6521 unicosmk t3e-unicosmk
1N/A sn9617 unicos CRAY_J90-unicos
1N/A SunOS solaris sun4-solaris
1N/A SunOS solaris i86pc-solaris
1N/A SunOS4 sunos sun4-sunos
1N/ABecause the value of C<$Config{archname}> may depend on the
1N/Ahardware architecture, it can vary more than the value of C<$^O>.
1N/A=head2 DOS and Derivatives
1N/APerl has long been ported to Intel-style microcomputers running under
1N/Asystems like PC-DOS, MS-DOS, OS/2, and most Windows platforms you can
1N/Abring yourself to mention (except for Windows CE, if you count that).
1N/Abe aware that each of these file specifications may have subtle
1N/ASystem calls accept either C</> or C<\> as the path separator.
1N/AHowever, many command-line utilities of DOS vintage treat C</> as
1N/Athe option prefix, so may get confused by filenames containing C</>.
1N/AAside from calling any external programs, C</> will work just fine,
1N/Aand probably better, as it is more consistent with popular usage,
1N/Aand avoids the problem of remembering what to backwhack and what
1N/AThe DOS FAT filesystem can accommodate only "8.3" style filenames. Under
1N/Athe "case-insensitive, but case-preserving" HPFS (OS/2) and NTFS (NT)
1N/Afilesystems you may have to be careful about case returned with functions
1N/Alike C<readdir> or used with functions like C<open> or C<opendir>.
1N/ADOS also treats several filenames as special, such as AUX, PRN,
1N/ANUL, CON, COM1, LPT1, LPT2, etc. Unfortunately, sometimes these
1N/Afilenames won't even work if you include an explicit directory
1N/Aprefix. It is best to avoid such filenames, if you want your code
1N/Ato be portable to DOS and its derivatives. It's hard to know what
1N/Athese all are, unfortunately.
1N/AUsers of these operating systems may also wish to make use of
1N/Aput wrappers around your scripts.
1N/ANewline (C<\n>) is translated as C<\015\012> by STDIO when reading from
1N/Aand writing to files (see L<"Newlines">). C<binmode(FILEHANDLE)>
1N/Awill keep C<\n> translated as C<\012> for that filehandle. Since it is a
1N/Ano-op on other systems, C<binmode> should be used for cross-platform code
1N/Athat deals with binary data. That's assuming you realize in advance
1N/Athat your data is in binary. General-purpose programs should
1N/Aoften assume nothing about their data.
1N/AThe C<$^O> variable and the C<$Config{archname}> values for various
1N/ADOSish perls are as follows:
1N/A OS $^O $Config{archname} ID Version
1N/A --------------------------------------------------------
1N/A Windows 3.1 ? ? 0 3 01
1N/A Windows 95 MSWin32 MSWin32-x86 1 4 00
1N/A Windows 98 MSWin32 MSWin32-x86 1 4 10
1N/A Windows ME MSWin32 MSWin32-x86 1 ?
1N/A Windows NT MSWin32 MSWin32-x86 2 4 xx
1N/A Windows NT MSWin32 MSWin32-ALPHA 2 4 xx
1N/A Windows NT MSWin32 MSWin32-ppc 2 4 xx
1N/A Windows 2000 MSWin32 MSWin32-x86 2 5 xx
1N/A Windows XP MSWin32 MSWin32-x86 2 ?
1N/A Windows CE MSWin32 ? 3
1N/AThe various MSWin32 Perl's can distinguish the OS they are running on
1N/Avia the value of the fifth element of the list returned from
1N/AWin32::GetOSVersion(). For example:
1N/A if ($^O eq 'MSWin32') {
1N/A my @os_version_info = Win32::GetOSVersion();
1N/A print +('3.1','95','NT')[$os_version_info[4]],"\n";
1N/AThere are also Win32::IsWinNT() and Win32::IsWin95(), try C<perldoc Win32>,
1N/Aand as of libwin32 0.19 (not part of the core Perl distribution)
1N/AWin32::GetOSName(). The very portable POSIX::uname() will work too:
1N/A c:\> perl -MPOSIX -we "print join '|', uname"
1N/A Windows NT|moonru|5.0|Build 2195 (Service Pack 2)|x86
1N/AThe EMX environment for DOS, OS/2, etc. emx@iaehv.nl,
1N/ABuild instructions for Win32 in L<perlwin32>, or under the Cygnus environment
1N/AThe C<Win32::*> modules in L<Win32>.
1N/ABuild instructions for OS/2, L<perlos2>
1N/AAny module requiring XS compilation is right out for most people, because
1N/AMacPerl is built using non-free (and non-cheap!) compilers. Some XS
1N/Amodules that can work with MacPerl are built and distributed in binary
1N/ADirectories are specified as:
1N/A volume:folder:file for absolute pathnames
1N/A volume:folder: for absolute pathnames
1N/A :folder:file for relative pathnames
1N/A :folder: for relative pathnames
1N/A :file for relative pathnames
1N/A file for relative pathnames
1N/AFiles are stored in the directory in alphabetical order. Filenames are
1N/Alimited to 31 characters, and may include any character except for
1N/Anull and C<:>, which is reserved as the path separator.
1N/AInstead of C<flock>, see C<FSpSetFLock> and C<FSpRstFLock> in the
1N/AMac::Files module, or C<chmod(0444, ...)> and C<chmod(0666, ...)>.
1N/AIn the MacPerl application, you can't run a program from the command line;
1N/Aprograms that expect C<@ARGV> to be populated can be edited with something
1N/Alike the following, which brings up a dialog box asking for the command
1N/A @ARGV = split /\s+/, MacPerl::Ask('Arguments?');
1N/AA MacPerl script saved as a "droplet" will populate C<@ARGV> with the full
1N/Apathnames of the files dropped onto the script.
1N/AMac users can run programs under a type of command line interface
1N/Aunder MPW (Macintosh Programmer's Workshop, a free development
1N/Aenvironment from Apple). MacPerl was first introduced as an MPW
1N/Atool, and MPW can be used like a shell:
1N/AToolServer is another app from Apple that provides access to MPW tools
1N/Afrom MPW and the MacPerl app, which allows MacPerl programs to use
1N/AC<system>, backticks, and piped C<open>.
1N/A"S<Mac OS>" is the proper name for the operating system, but the value
1N/Ain C<$^O> is "MacOS". To determine architecture, version, or whether
1N/Athe application or MPW tool version is running, check:
1N/A $is_app = $MacPerl::Version =~ /App/;
1N/A $is_tool = $MacPerl::Version =~ /MPW/;
1N/A ($version) = $MacPerl::Version =~ /^(\S+)/;
1N/A $is_ppc = $MacPerl::Architecture eq 'MacPPC';
1N/A $is_68k = $MacPerl::Architecture eq 'Mac68K';
1N/AS<Mac OS X>, based on NeXT's OpenStep OS, runs MacPerl natively, under the
1N/A"Classic" environment. There is no "Carbon" version of MacPerl to run
1N/Aunder the primary Mac OS X environment. S<Mac OS X> and its Open Source
1N/Aversion, Darwin, both run Unix perl natively.
1N/APerl on VMS is discussed in L<perlvms> in the perl distribution.
1N/APerl on VMS can accept either VMS- or Unix-style file
1N/Aspecifications as in either of the following:
1N/Abut not a mixture of both as in:
1N/A Can't open sys$login:/
login.com: file specification syntax error
1N/AInteracting with Perl from the Digital Command Language (DCL) shell
1N/Aoften requires a different set of quotation marks than Unix shells do.
1N/A $ perl -e "print ""Hello, world.\n"""
1N/AThere are several ways to wrap your perl scripts in DCL F<.COM> files, if
1N/Ayou are so inclined. For example:
1N/A $ write sys$output "Hello from DCL!"
1N/A $ then perl -x 'f$environment("PROCEDURE")
1N/A $ else perl -x - 'p1 'p2 'p3 'p4 'p5 'p6 'p7 'p8
1N/A print "Hello from Perl!\n";
1N/Aperl-in-DCL script expects to do things like C<< $read = <STDIN>; >>.
1N/Alength for filenames is 39 characters, and the maximum length for
1N/Aextensions is also 39 characters. Version is a number from 1 to
1N/A32767. Valid characters are C</[A-Z0-9$_-]/>.
1N/AVMS's RMS filesystem is case-insensitive and does not preserve case.
1N/AC<readdir> returns lowercased filenames, but specifying a file for
1N/Aopening remains case-insensitive. Files without extensions have a
1N/Atrailing period on them, so doing a C<readdir> with a file named F<A.;5>
1N/Awill return F<a.> (though that file could be opened with
1N/ARMS had an eight level limit on directory depths from any rooted logical
1N/A(allowing 16 levels overall) prior to VMS 7.2. Hence
1N/AC<PERL_ROOT:[LIB.2.3.4.5.6.7.8]> is a valid directory specification but
1N/AC<PERL_ROOT:[LIB.2.3.4.5.6.7.8.9]> is not. F<
Makefile.PL> authors might
1N/Ahave to take this into account, but at least they can refer to the former
1N/AThe VMS::Filespec module, which gets installed as part of the build
1N/Aprocess on VMS, is a pure Perl module that can easily be installed on
1N/Anon-VMS platforms and can be helpful for conversions to and from RMS
1N/AWhat C<\n> represents depends on the type of file opened. It usually
1N/Arepresents C<\012> but it could also be C<\015>, C<\012>, C<\015\012>,
1N/AC<\000>, C<\040>, or nothing depending on the file organiztion and
1N/Arecord format. The VMS::Stdio module provides access to the
1N/Aspecial fopen() requirements of files with unusual attributes on VMS.
1N/ATCP/IP stacks are optional on VMS, so socket routines might not be
1N/Aimplemented. UDP sockets may not be supported.
1N/AThe value of C<$^O> on OpenVMS is "VMS". To determine the architecture
1N/Athat you are running on without resorting to loading all of C<%Config>
1N/Ayou can examine the content of the C<@INC> array like so:
1N/A if (grep(/VMS_AXP/, @INC)) {
1N/A print "I'm on Alpha!\n";
1N/A } elsif (grep(/VMS_VAX/, @INC)) {
1N/A print "I'm on VAX!\n";
1N/A print "I'm not so sure about where $^O is...\n";
1N/AOn VMS, perl determines the UTC offset from the C<SYS$TIMEZONE_DIFFERENTIAL>
1N/Alogical name. Although the VMS epoch began at 17-NOV-1858 00:00:00.00,
1N/Acalls to C<localtime> are adjusted to count offsets from
1N/A01-JAN-1970 00:00:00.00, just like Unix.
1N/Avmsperl list, majordomo@perl.org
1N/A(Put the words C<subscribe vmsperl> in message body.)
1N/APerl on VOS is discussed in F<
README.vos> in the perl distribution
1N/A(installed as L<perlvos>). Perl on VOS can accept either VOS- or
1N/AUnix-style file specifications as in either of the following:
1N/A C<< $ perl -ne "print if /perl_setup/i" >system>notices >>
1N/Aor even a mixture of both as in:
1N/AEven though VOS allows the slash character to appear in object
1N/Anames, because the VOS port of Perl interprets it as a pathname
1N/Adelimiting character, VOS files, directories, or links whose names
1N/Acontain a slash character cannot be processed. Such files must be
1N/Arenamed before they can be processed by Perl. Note that VOS limits
1N/Afile names to 32 or fewer characters.
1N/APerl on VOS can be built using two different compilers and two different
1N/Aversions of the POSIX runtime. The recommended method for building full
1N/APerl is with the GNU C compiler and the generally-available version of
1N/AVOS POSIX support. See F<
README.vos> (installed as L<perlvos>) for
1N/Arestrictions that apply when Perl is built using the VOS Standard C
1N/Acompiler or the alpha version of VOS POSIX support.
1N/AThe value of C<$^O> on VOS is "VOS". To determine the architecture that
1N/Ayou are running on without resorting to loading all of C<%Config> you
1N/Acan examine the content of the @INC array like so:
1N/A print "I'm on a Stratus box!\n";
1N/A print "I'm not on a Stratus box!\n";
1N/A if (grep(/860/, @INC)) {
1N/A print "This box is a Stratus XA/R!\n";
1N/A } elsif (grep(/7100/, @INC)) {
1N/A print "This box is a Stratus HP 7100 or 8xxx!\n";
1N/A } elsif (grep(/8000/, @INC)) {
1N/A print "This box is a Stratus HP 8xxx!\n";
1N/A print "This box is a Stratus 68K!\n";
1N/AThe VOS mailing list.
1N/AThere is no specific mailing list for Perl on VOS. You can post
1N/AStratus mailing list. Send a letter with "subscribe Info-Stratus" in
1N/Athe message body to majordomo@list.stratagy.com.
1N/A=head2 EBCDIC Platforms
1N/ARecent versions of Perl have been ported to platforms such as OS/400 on
1N/AAS/400 minicomputers as well as OS/390,
VM/ESA, and BS2000 for S/390
1N/AMainframes. Such computers use EBCDIC character sets internally (usually
1N/ACharacter Code Set ID 0037 for OS/400 and either 1047 or POSIX-BC for S/390
1N/Asystems). On the mainframe perl currently works under the "Unix system
1N/Aservices for OS/390" (formerly known as OpenEdition),
VM/ESA OpenEdition, or
1N/Athe BS200 POSIX-BC system (BS2000 is supported in perl 5.6 and greater).
1N/ASee L<perlos390> for details. Note that for OS/400 there is also a port of
1N/APerl 5.8.1/5.9.0 or later to the PASE which is ASCII-based (as opposed to
1N/AILE which is EBCDIC-based), see L<perlos400>.
1N/AAs of R2.5 of USS for OS/390 and Version 2.3 of
VM/ESA these Unix
1N/Asub-systems do not support the C<#!> shebang trick for script invocation.
1N/AHence, on OS/390 and
VM/ESA perl scripts can be executed with a header
1N/Asimilar to the following simple script:
1N/A print "Hello from perl!\n";
1N/AOS/390 will support the C<#!> shebang trick in release 2.8 and beyond.
1N/ACalls to C<system> and backticks can use POSIX shell syntax on all
1N/AOn the AS/400, if PERL5 is in your library list, you may need
1N/Ato wrap your perl scripts in a CL procedure to invoke them like so:
1N/AThis will invoke the perl script F<
hello.pl> in the root of the
1N/AQOpenSys file system. On the AS/400 calls to C<system> or backticks
1N/AOn these platforms, bear in mind that the EBCDIC character set may have
1N/Aan effect on what happens with some perl functions (such as C<chr>,
1N/AC<pack>, C<print>, C<printf>, C<ord>, C<sort>, C<sprintf>, C<unpack>), as
1N/Awell as bit-fiddling with ASCII constants using operators like C<^>, C<&>
1N/Aand C<|>, not to mention dealing with socket interfaces to ASCII computers
1N/AFortunately, most web servers for the mainframe will correctly
1N/Atranslate the C<\n> in the following statement to its ASCII equivalent
1N/A(C<\r> is the same under both Unix and OS/390 &
VM/ESA):
1N/AThe values of C<$^O> on some of these platforms includes:
1N/A uname $^O $Config{'archname'}
1N/A --------------------------------------------
1N/A POSIX-BC posix-bc BS2000-posix-bc
1N/ASome simple tricks for determining if you are running on an EBCDIC
1N/Aplatform could include any of the following (perhaps all):
1N/A if ("\t" eq "\05") { print "EBCDIC may be spoken here!\n"; }
1N/A if (ord('A') == 193) { print "EBCDIC may be spoken here!\n"; }
1N/A if (chr(169) eq 'z') { print "EBCDIC may be spoken here!\n"; }
1N/AOne thing you may not want to rely on is the EBCDIC encoding
1N/Aof punctuation characters since these may differ from code page to code
1N/Apage (and once your module or script is rumoured to work with EBCDIC,
1N/Afolks will want it to work with all EBCDIC character sets).
1N/AThe perl-mvs@perl.org list is for discussion of porting issues as well as
1N/Ageneral usage issues for all EBCDIC Perls. Send a message body of
1N/A"subscribe perl-mvs" to majordomo@perl.org.
1N/AAS/400 Perl information at
1N/Aas well as on CPAN in the F<ports/> directory.
1N/ABecause Acorns use ASCII with newlines (C<\n>) in text files as C<\012> like
1N/AUnix, and because Unix filename emulation is turned on by default,
1N/Amost simple scripts will probably work "out of the box". The native
1N/Afilesystem is modular, and individual filesystems are free to be
1N/Acase-sensitive or insensitive, and are usually case-preserving. Some
1N/Anative filesystems have name length limits, which file and directory
1N/Anames are silently truncated to fit. Scripts should be aware that the
1N/Astandard filesystem currently has a name length limit of B<10>
1N/Acharacters, with up to 77 items in a directory, but other filesystems
1N/Amay not impose such limitations.
1N/ANative filenames are of the form
1N/A Special_Field is not usually present, but may contain . and $ .
1N/A Filesystem =~ m|[A-Za-z0-9_]|
1N/A DsicName =~ m|[A-Za-z0-9_/]|
1N/A $ represents the root directory
1N/A . is the path separator
1N/A @ is the current directory (per filesystem but machine global)
1N/A ^ is the parent directory
1N/A Directory and File =~ m|[^\0- "\.\$\%\&:\@\\^\|\177]+|
1N/AThe default filename translation is roughly C<tr|/.|./|;>
1N/ANote that C<"ADFS::HardDisk.$.File" ne 'ADFS::HardDisk.$.File'> and that
1N/Athe second stage of C<$> interpolation in regular expressions will fall
1N/Afoul of the C<$.> if scripts are not careful.
1N/ALogical paths specified by system variables containing comma-separated
1N/Asearch lists are also allowed; hence C<System:Modules> is a valid
1N/Afilename, and the filesystem will prefix C<Modules> with each section of
1N/AC<System$Path> until a name is made that points to an object on disk.
1N/AWriting to a new file C<System:Modules> would be allowed only if
1N/AC<System$Path> contains a single item list. The filesystem will also
1N/Aexpand system variables in filenames if enclosed in angle brackets, so
1N/AC<< <System$Dir>.Modules >> would look for the file
1N/AS<C<$ENV{'System$Dir'} . 'Modules'>>. The obvious implication of this is
1N/Athat B<fully qualified filenames can start with C<< <> >>> and should
1N/Abe protected when C<open> is used for input.
1N/ABecause C<.> was in use as a directory separator and filenames could not
1N/Abe assumed to be unique after 10 characters, Acorn implemented the C
1N/Acompiler to strip the trailing C<.c> C<.h> C<.s> and C<.o> suffix from
1N/Afilenames specified in source code and store the respective files in
1N/Asubdirectories named after the suffix. Hence files are translated:
1N/AThe Unix emulation library's translation of filenames to native assumes
1N/Athat this sort of translation is required, and it allows a user-defined list
1N/Aof known suffixes that it will transpose in this fashion. This may
1N/AC<glob> cannot and do not attempt to emulate the reverse mapping. Other
1N/AC<.>'s in filenames are translated to C</>.
1N/AAs implied above, the environment accessed through C<%ENV> is global, and
1N/Athe convention is that program specific environment variables are of the
1N/Aform C<Program$Name>. Each filesystem maintains a current directory,
1N/Aand the current filesystem's current directory is the B<global> current
1N/Adirectory. Consequently, sociable programs don't change the current
1N/Adirectory but rely on full pathnames, and programs (and Makefiles) cannot
1N/Aassume that they can spawn a child process which can change the current
1N/Adirectory without affecting its parent (and everyone else for that
1N/ABecause native operating system filehandles are global and are currently
1N/Aallocated down from 255, with 0 being a reserved value, the Unix emulation
1N/Alibrary emulates Unix filehandles. Consequently, you can't rely on
1N/Apassing C<STDIN>, C<STDOUT>, or C<STDERR> to your children.
1N/AThe desire of users to express filenames of the form
1N/AC<< <Foo$Dir>.Bar >> on the command line unquoted causes problems,
1N/Atoo: C<``> command output capture has to perform a guessing game. It
1N/Aassumes that a string C<< <[^<>]+\$[^<>]> >> is a
1N/Areference to an environment variable, whereas anything else involving
1N/AC<< < >> or C<< > >> is redirection, and generally manages to be 99%
1N/Aright. Of course, the problem remains that scripts cannot rely on any
1N/AUnix tools being available, or that any tools found have Unix-like command
1N/AExtensions and XS are, in theory, buildable by anyone using free
1N/Atools. In practice, many don't, as users of the Acorn platform are
1N/Aused to binary distributions. MakeMaker does run, but no available
1N/Amake currently copes with MakeMaker's makefiles; even if and when
1N/Athis should be fixed, the lack of a Unix-like shell will cause
1N/Aproblems with makefile rules, especially lines of the form C<cd
1N/Asdbm && make all>, and anything using quoting.
1N/A"S<RISC OS>" is the proper name for the operating system, but the value
1N/Ain C<$^O> is "riscos" (because we don't like shouting).
1N/APerl has been ported to many platforms that do not fit into any of
1N/Athe categories listed above. Some, such as AmigaOS, Atari MiNT,
1N/ABeOS, HP
MPE/iX, QNX, Plan 9, and VOS, have been well-integrated
1N/Ainto the standard Perl source code kit. You may need to see the
1N/AF<ports/> directory on CPAN for information, and possibly binaries,
1N/Afor the likes of: aos, Atari ST, lynxos, riscos, Novell Netware,
1N/ATandem Guardian, I<etc.> (Yes, we know that some of these OSes may
1N/Afall under the Unix category, but we are not a standards body.)
1N/ASome approximate operating system names and their C<$^O> values
1N/Ain the "OTHER" category include:
1N/A OS $^O $Config{'archname'}
1N/A ------------------------------------------
1N/A Amiga DOS amigaos m68k-amigos
1N/AA free perl5-based
PERL.NLM for Novell Netware is available in
1N/Aas well as from CPAN.
1N/A=head1 FUNCTION IMPLEMENTATIONS
1N/AListed below are functions that are either completely unimplemented
1N/Aor else have been implemented differently on various platforms.
1N/AFollowing each description will be, in parentheses, a list of
1N/Aplatforms that the description applies to.
1N/AThe list may well be incomplete, or even wrong in some places. When
1N/Ain doubt, consult the platform-specific README files in the Perl
1N/Asource distribution, and any other documentation resources accompanying
1N/ABe aware, moreover, that even among Unix-ish systems there are variations.
1N/AFor many functions, you can also query C<%Config>, exported by
1N/Adefault from the Config module. For example, to check whether the
1N/Aplatform has the C<lstat> call, check C<$Config{d_lstat}>. See
1N/AL<Config> for a full description of available variables.
1N/A=head2 Alphabetical Listing of Perl Functions
1N/AC<-r>, C<-w>, and C<-x> have a limited meaning only; directories
1N/Aand applications are executable, and there are no
uid/gid 1N/Aconsiderations. C<-o> is not supported. (S<Mac OS>)
1N/AC<-r>, C<-w>, C<-x>, and C<-o> tell whether the file is accessible,
1N/Awhich may not reflect UIC-based file protections. (VMS)
1N/AC<-s> returns the size of the data fork, not the total size of data fork
1N/Aplus resource fork. (S<Mac OS>).
1N/AC<-s> by name on an open file will return the space reserved on disk,
1N/Arather than the current extent. C<-s> on an open filehandle returns the
1N/Acurrent size. (S<RISC OS>)
1N/AC<-R>, C<-W>, C<-X>, C<-O> are indistinguishable from C<-r>, C<-w>,
1N/AC<-x>, C<-o>. (S<Mac OS>, Win32, VMS, S<RISC OS>)
1N/AC<-b>, C<-c>, C<-k>, C<-g>, C<-p>, C<-u>, C<-A> are not implemented.
1N/AC<-g>, C<-k>, C<-l>, C<-p>, C<-u>, C<-A> are not particularly meaningful.
1N/A(Win32, VMS, S<RISC OS>)
1N/AC<-d> is true if passed a device spec without an explicit directory.
1N/AC<-T> and C<-B> are implemented, but might misclassify Mac text files
1N/Awith foreign characters; this is the case will all platforms, but may
1N/Aaffect S<Mac OS> often. (S<Mac OS>)
1N/AC<-x> (or C<-X>) determine if a file ends in one of the executable
1N/Asuffixes. C<-S> is meaningless. (Win32)
1N/AC<-x> (or C<-X>) determine if a file has an executable file type.
1N/A=item binmode FILEHANDLE
1N/AMeaningless. (S<Mac OS>, S<RISC OS>)
1N/AReopens file and restores pointer; if function fails, underlying
1N/Afilehandle may be closed, or pointer may be in a different position.
1N/AThe value returned by C<tell> may be affected after the call, and
1N/Athe filehandle may be flushed. (Win32)
1N/AOnly good for changing "owner" read-write access, "group", and "other"
1N/Abits are meaningless. (Win32)
1N/AOnly good for changing "owner" and "other" read-write access. (S<RISC OS>)
1N/AAccess permissions are mapped onto VOS access-control list changes. (VOS)
1N/AThe actual permissions set depend on the value of the C<CYGWIN>
1N/Ain the SYSTEM environment settings. (Cygwin)
1N/ANot implemented. (S<Mac OS>, Win32, S<Plan 9>, S<RISC OS>, VOS)
1N/ADoes nothing, but won't fail. (Win32)
1N/A=item chroot FILENAME
1N/ANot implemented. (S<Mac OS>, Win32, VMS, S<Plan 9>, S<RISC OS>, VOS,
VM/ESA)
1N/A=item crypt PLAINTEXT,SALT
1N/AMay not be available if library or source was not provided when building
1N/ANot implemented. (VOS)
1N/ANot implemented. (VMS, S<Plan 9>, VOS)
1N/A=item dbmopen HASH,DBNAME,MODE
1N/ANot implemented. (VMS, S<Plan 9>, VOS)
1N/ANot useful. (S<Mac OS>, S<RISC OS>)
1N/ANot implemented. (Win32)
1N/AInvokes VMS debugger. (VMS)
1N/ANot implemented. (S<Mac OS>)
1N/ADoes not automatically flush output handles on some platforms.
1N/A(SunOS, Solaris, HP-UX)
1N/AEmulates UNIX exit() (which considers C<exit 1> to indicate an error) by
1N/Amapping the C<1> to SS$_ABORT (C<44>). This behavior may be overridden
1N/Awith the pragma C<use vmsish 'exit'>. As with the CRTL's exit()
1N/Afunction, C<exit 0> is also mapped to an exit status of SS$_NORMAL
1N/A(C<1>); this mapping cannot be overridden. Any other argument to exit()
1N/Ais used directly as Perl's exit status. (VMS)
1N/A=item fcntl FILEHANDLE,FUNCTION,SCALAR
1N/ANot implemented. (Win32, VMS)
1N/A=item flock FILEHANDLE,OPERATION
1N/ANot implemented (S<Mac OS>, VMS, S<RISC OS>, VOS).
1N/AAvailable only on Windows NT (not on Windows 95). (Win32)
1N/ANot implemented. (S<Mac OS>, AmigaOS, S<RISC OS>, VOS,
VM/ESA, VMS)
1N/AEmulated using multiple interpreters. See L<perlfork>. (Win32)
1N/ADoes not automatically flush output handles on some platforms.
1N/A(SunOS, Solaris, HP-UX)
1N/ANot implemented. (S<Mac OS>, S<RISC OS>)
1N/ANot implemented. (S<Mac OS>, Win32, VMS, S<RISC OS>, VOS)
1N/ANot implemented. (S<Mac OS>, Win32, S<RISC OS>)
1N/A=item getpriority WHICH,WHO
1N/ANot implemented. (S<Mac OS>, Win32, VMS, S<RISC OS>, VOS,
VM/ESA)
1N/ANot implemented. (S<Mac OS>, Win32)
1N/ANot useful. (S<RISC OS>)
1N/ANot implemented. (S<Mac OS>, Win32, VMS, S<RISC OS>)
1N/A=item getnetbyname NAME
1N/ANot implemented. (S<Mac OS>, Win32, S<Plan 9>)
1N/ANot implemented. (S<Mac OS>, Win32)
1N/ANot useful. (S<RISC OS>)
1N/ANot implemented. (S<Mac OS>, Win32, VMS, S<RISC OS>)
1N/A=item getnetbyaddr ADDR,ADDRTYPE
1N/ANot implemented. (S<Mac OS>, Win32, S<Plan 9>)
1N/A=item getprotobynumber NUMBER
1N/ANot implemented. (S<Mac OS>)
1N/A=item getservbyport PORT,PROTO
1N/ANot implemented. (S<Mac OS>)
1N/ANot implemented. (S<Mac OS>, Win32, VMS,
VM/ESA)
1N/AC<gethostbyname('localhost')> does not work everywhere: you may have
1N/Ato use C<gethostbyname('127.0.0.1')>. (S<Mac OS>, S<Irix 5>)
1N/ANot implemented. (S<Mac OS>, Win32)
1N/ANot implemented. (S<Mac OS>, Win32, S<Plan 9>)
1N/ANot implemented. (S<Mac OS>, Win32, S<Plan 9>)
1N/ANot implemented. (Win32, S<Plan 9>)
1N/A=item sethostent STAYOPEN
1N/ANot implemented. (S<Mac OS>, Win32, S<Plan 9>, S<RISC OS>)
1N/A=item setnetent STAYOPEN
1N/ANot implemented. (S<Mac OS>, Win32, S<Plan 9>, S<RISC OS>)
1N/A=item setprotoent STAYOPEN
1N/ANot implemented. (S<Mac OS>, Win32, S<Plan 9>, S<RISC OS>)
1N/A=item setservent STAYOPEN
1N/ANot implemented. (S<Plan 9>, Win32, S<RISC OS>)
1N/ANot implemented. (S<Mac OS>, Win32)
1N/ANot implemented. (S<Mac OS>, Win32, S<Plan 9>)
1N/ANot implemented. (S<Mac OS>, Win32, S<Plan 9>)
1N/ANot implemented. (S<Plan 9>, Win32)
1N/A=item getsockopt SOCKET,LEVEL,OPTNAME
1N/ANot implemented. (S<Plan 9>)
1N/AThis operator is implemented via the File::Glob extension on most
1N/Aplatforms. See L<File::Glob> for portability information.
1N/A=item ioctl FILEHANDLE,FUNCTION,SCALAR
1N/ANot implemented. (VMS)
1N/AAvailable only for socket handles, and it does what the ioctlsocket() call
1N/Ain the Winsock API does. (Win32)
1N/AAvailable only for socket handles. (S<RISC OS>)
1N/A=item kill SIGNAL, LIST
1N/AC<kill(0, LIST)> is implemented for the sake of taint checking;
1N/Ause with other signals is unimplemented. (S<Mac OS>)
1N/ANot implemented, hence not useful for taint checking. (S<RISC OS>)
1N/AC<kill()> doesn't have the semantics of C<raise()>,
i.e. it doesn't send
1N/Aa signal to the identified process like it does on Unix platforms.
1N/AInstead C<kill($sig, $pid)> terminates the process identified by $pid,
1N/Aand makes it exit immediately with exit status $sig. As in Unix, if
1N/A$sig is 0 and the specified process exists, it returns true without
1N/Aactually terminating it. (Win32)
1N/A=item link OLDFILE,NEWFILE
1N/ANot implemented. (S<Mac OS>,
MPE/iX, VMS, S<RISC OS>)
1N/ALink count not updated because hard links are not quite that hard
1N/A(They are sort of half-way between hard and soft links). (AmigaOS)
1N/AHard links are implemented on Win32 (Windows NT and Windows 2000)
1N/A=item lstat FILEHANDLE
1N/ANot implemented. (VMS, S<RISC OS>)
1N/AReturn values (especially for device and inode) may be bogus. (Win32)
1N/A=item msgctl ID,CMD,ARG
1N/A=item msgget KEY,FLAGS
1N/A=item msgsnd ID,MSG,FLAGS
1N/A=item msgrcv ID,VAR,SIZE,TYPE,FLAGS
1N/ANot implemented. (S<Mac OS>, Win32, VMS, S<Plan 9>, S<RISC OS>, VOS)
1N/A=item open FILEHANDLE,EXPR
1N/A=item open FILEHANDLE
1N/AThe C<|> variants are supported only if ToolServer is installed.
1N/Aopen to C<|-> and C<-|> are unsupported. (S<Mac OS>, Win32, S<RISC OS>)
1N/AOpening a process does not automatically flush output handles on some
1N/Aplatforms. (SunOS, Solaris, HP-UX)
1N/A=item pipe READHANDLE,WRITEHANDLE
1N/AVery limited functionality. (MiNT)
1N/ANot implemented. (Win32, VMS, S<RISC OS>)
1N/A=item select RBITS,WBITS,EBITS,TIMEOUT
1N/AOnly implemented on sockets. (Win32, VMS)
1N/AOnly reliable on sockets. (S<RISC OS>)
1N/ANote that the C<select FILEHANDLE> form is generally portable.
1N/A=item semctl ID,SEMNUM,CMD,ARG
1N/A=item semget KEY,NSEMS,FLAGS
1N/A=item semop KEY,OPSTRING
1N/ANot implemented. (S<Mac OS>, Win32, VMS, S<RISC OS>, VOS)
1N/ANot implemented. (S<Mac OS>,
MPE/iX, VMS, Win32, S<RISC OS>)
1N/A=item setpgrp PID,PGRP
1N/ANot implemented. (S<Mac OS>, Win32, VMS, S<RISC OS>, VOS)
1N/A=item setpriority WHICH,WHO,PRIORITY
1N/ANot implemented. (S<Mac OS>, Win32, VMS, S<RISC OS>, VOS)
1N/ANot implemented. (S<Mac OS>,
MPE/iX, Win32, S<RISC OS>)
1N/A=item setsockopt SOCKET,LEVEL,OPTNAME,OPTVAL
1N/ANot implemented. (S<Plan 9>)
1N/A=item shmctl ID,CMD,ARG
1N/A=item shmget KEY,SIZE,FLAGS
1N/A=item shmread ID,VAR,POS,SIZE
1N/A=item shmwrite ID,STRING,POS,SIZE
1N/ANot implemented. (S<Mac OS>, Win32, VMS, S<RISC OS>, VOS)
1N/A=item sockatmark SOCKET
1N/AA relatively recent addition to socket functions, may not
1N/Abe implemented even in UNIX platforms.
1N/A=item socketpair SOCKET1,SOCKET2,DOMAIN,TYPE,PROTOCOL
1N/ANot implemented. (Win32, VMS, S<RISC OS>, VOS,
VM/ESA)
1N/A=item stat FILEHANDLE
1N/APlatforms that do not have rdev, blksize, or blocks will return these
1N/Aas '', so numeric comparison or manipulation of these fields may cause
1N/A'not numeric' warnings.
1N/Amtime and atime are the same thing, and ctime is creation time instead of
1N/Ainode change time. (S<Mac OS>).
1N/Actime not supported on UFS (S<Mac OS X>).
1N/Actime is creation time instead of inode change time (Win32).
1N/Adevice and inode are not meaningful. (Win32)
1N/Adevice and inode are not necessarily reliable. (VMS)
1N/Amtime, atime and ctime all return the last modification time. Device and
1N/Ainode are not necessarily reliable. (S<RISC OS>)
1N/Adev, rdev, blksize, and blocks are not available. inode is not
1N/Ameaningful and will differ between stat calls on the same file. (os2)
1N/Asome versions of cygwin when doing a stat("foo") and if not finding it
1N/A=item symlink OLDFILE,NEWFILE
1N/ANot implemented. (Win32, VMS, S<RISC OS>)
1N/ANot implemented. (S<Mac OS>, Win32, VMS, S<RISC OS>, VOS,
VM/ESA)
1N/A=item sysopen FILEHANDLE,FILENAME,MODE,PERMS
1N/AThe traditional "0", "1", and "2" MODEs are implemented with different
1N/Anumeric values on some systems. The flags exported by C<Fcntl>
1N/A(O_RDONLY, O_WRONLY, O_RDWR) should work everywhere though. (S<Mac
1N/AIn general, do not assume the
UNIX/POSIX semantics that you can shift
1N/AC<$?> right by eight to get the exit value, or that C<$? & 127>
1N/Awould give you the number of the signal that terminated the program,
1N/Aor that C<$? & 128> would test true if the program was terminated by a
1N/Acoredump. Instead, use the POSIX W*() interfaces: for example, use
1N/AWIFEXITED($?) and WEXITVALUE($?) to test for a normal exit and the exit
1N/Avalue, WIFSIGNALED($?) and WTERMSIG($?) for a signal exit and the
1N/Asignal. Core dumping is not a portable concept, so there's no portable
1N/Away to test for that.
1N/AOnly implemented if ToolServer is installed. (S<Mac OS>)
1N/AAs an optimization, may not call the command shell specified in
1N/AC<$ENV{PERL5SHELL}>. C<system(1, @args)> spawns an external
1N/Aprocess and immediately returns its process designator, without
1N/Awaiting for it to terminate. Return value may be used subsequently
1N/Ain C<wait> or C<waitpid>. Failure to spawn() a subprocess is indicated
1N/Aby setting $? to "255 << 8". C<$?> is set in a way compatible with
1N/AUnix (
i.e. the exitstatus of the subprocess is obtained by "$? >> 8",
1N/Aas described in the documentation). (Win32)
1N/AThere is no shell to process metacharacters, and the native standard is
1N/Ato pass a command line terminated by "\n" "\r" or "\0" to the spawned
1N/Aprogram. Redirection such as C<< > foo >> is performed (if at all) by
1N/Athe run time library of the spawned program. C<system> I<list> will call
1N/Athe Unix emulation library's C<exec> emulation, which attempts to provide
1N/Aemulation of the stdin, stdout, stderr in force in the parent, providing
1N/Athe child program uses a compatible version of the emulation library.
1N/AI<scalar> will call the native command line direct and no such emulation
1N/Aof a child Unix program will exists. Mileage B<will> vary. (S<RISC OS>)
1N/AFar from being POSIX compliant. Because there may be no underlying
1N/A/bin/sh tries to work around the problem by forking and execing the
1N/Afirst token in its argument string. Handles basic redirection
1N/A("<" or ">") on its own behalf. (MiNT)
1N/ADoes not automatically flush output handles on some platforms.
1N/A(SunOS, Solaris, HP-UX)
1N/AThe return value is POSIX-like (shifted up by 8 bits), which only allows
1N/Aroom for a made-up value derived from the severity bits of the native
1N/A32-bit condition code (unless overridden by C<use vmsish 'status'>).
1N/AFor more details see L<perlvms/$?>. (VMS)
1N/AOnly the first entry returned is nonzero. (S<Mac OS>)
1N/A"cumulative" times will be bogus. On anything other than Windows NT
1N/Aor Windows 2000, "system" time will be bogus, and "user" time is
1N/Aactually the time returned by the clock() function in the C runtime
1N/ANot useful. (S<RISC OS>)
1N/A=item truncate FILEHANDLE,LENGTH
1N/A=item truncate EXPR,LENGTH
1N/ANot implemented. (Older versions of VMS)
1N/ATruncation to zero-length only. (VOS)
1N/AIf a FILEHANDLE is supplied, it must be writable and opened in append
1N/Amode (
i.e., use C<<< open(FH, '>>filename') >>>
1N/Aor C<sysopen(FH,...,O_APPEND|O_RDWR)>. If a filename is supplied, it
1N/Ashould not be held open elsewhere. (Win32)
1N/AReturns undef where unavailable, as of version 5.005.
1N/AC<umask> works but the correct permissions are set only when the file
1N/Ais finally closed. (AmigaOS)
1N/AOnly the modification time is updated. (S<BeOS>, S<Mac OS>, VMS, S<RISC OS>)
1N/AMay not behave as expected. Behavior depends on the C runtime
1N/Alibrary's implementation of utime(), and the filesystem being
1N/Aused. The FAT filesystem typically does not support an "access
1N/Atime" field, and it may limit timestamps to a granularity of
1N/A=item waitpid PID,FLAGS
1N/ANot implemented. (S<Mac OS>, VOS)
1N/ACan only be applied to process handles returned for processes spawned
1N/Ausing C<system(1, ...)> or pseudo processes created with C<fork()>. (Win32)
1N/ANot useful. (S<RISC OS>)
1N/A=item v1.48, 02 February 2001
1N/AVarious updates from perl5-porters over the past year, supported
1N/Aplatforms update from Jarkko Hietaniemi.
1N/A=item v1.47, 22 March 2000
1N/AVarious cleanups from Tom Christiansen, including migration of
1N/Along platform listings from L<perl>.
1N/A=item v1.46, 12 February 2000
1N/AUpdates for VOS and
MPE/iX. (Peter Prymmer) Other small changes.
1N/A=item v1.45, 20 December 1999
1N/ASmall changes from 5.005_63 distribution, more changes to EBCDIC info.
1N/A=item v1.44, 19 July 1999
1N/AA bunch of updates from Peter Prymmer for C<$^O> values,
1N/Aendianness, File::Spec, VMS, BS2000, OS/400.
1N/A=item v1.43, 24 May 1999
1N/AAdded a lot of cleaning up from Tom Christiansen.
1N/A=item v1.42, 22 May 1999
1N/A=item v1.41, 19 May 1999
1N/ALots more little changes to formatting and content.
1N/AAdded a bunch of C<$^O> and related values
1N/Afor various platforms; fixed mail and web addresses, and added
1N/Aand changed miscellaneous notes. (Peter Prymmer)
1N/A=item v1.40, 11 April 1999
1N/AMiscellaneous changes.
1N/A=item v1.39, 11 February 1999
1N/AChanges from Jarkko and EMX URL fixes Michael Schwern. Additional
1N/Anote about newlines added.
1N/A=item v1.38, 31 December 1998
1N/AMore changes from Jarkko.
1N/A=item v1.37, 19 December 1998
1N/AMore minor changes. Merge two separate version 1.35 documents.
1N/A=item v1.36, 9 September 1998
1N/AUpdated for Stratus VOS. Also known as version 1.35.
1N/A=item v1.35, 13 August 1998
1N/AIntegrate more minor changes, plus addition of new sections under
1N/AL<"ISSUES">: L<"Numbers endianness and Width">,
1N/AL<"Character sets and character encoding">,
1N/AL<"Internationalisation">.
1N/A=item v1.33, 06 August 1998
1N/AIntegrate more minor changes.
1N/A=item v1.32, 05 August 1998
1N/AIntegrate more minor changes.
1N/A=item v1.30, 03 August 1998
1N/AMajor update for RISC OS, other minor changes.
1N/A=item v1.23, 10 July 1998
1N/AFirst public release with perl5.005.
1N/A=head1 Supported Platforms
1N/AAs of September 2003 (the Perl release 5.8.1), the following platforms
1N/Aare able to build Perl from the standard source code distribution
1N/A HI-UXMPP (Hitachi) (5.8.0 worked but we didn't know it)
1N/A ReliantUNIX (formerly SINIX)
1N/A OpenVMS (formerly VMS)
1N/A Open UNIX (Unixware) (since Perl 5.8.1/5.9.0)
1N/A OS/400 (using the PASE) (since Perl 5.8.1/5.9.0)
1N/A POSIX-BC (formerly BS2000)
1N/A Tru64 UNIX (formerly DEC OSF/1, Digital UNIX)
1N/A Win95/98/ME/2K/XP 2)
1N/A 1) in DOS mode either the DOS or OS/2 ports can be used
1N/A 2) compilers: Borland, MinGW (GCC), VC6
1N/AThe following platforms worked with the previous releases (5.6 and
1N/A5.7), but we did not manage either to fix or to test these in time
1N/Afor the 5.8.1 release. There is a very good chance that many of these
1N/Awill work fine with the 5.8.1.
1N/AKnown to be broken for 5.8.0 and 5.8.1 (but 5.6.1 and 5.7.2 can be used):
1N/AThe following platforms have been known to build Perl from source in
1N/Athe past (5.005_03 and earlier), but we haven't been able to verify
1N/Atheir status for the current release, either because the
1N/Aactive champion on these platforms--or both. They used to work,
1N/Athough, so go ahead and try compiling them, and let perlbug@perl.org
1N/AThe following platforms have their own source code distributions and
1N/A OS/400 (ILE) 5.005_02
1N/A Tandem Guardian 5.004
1N/AThe following platforms have only binaries available via
1N/A Acorn RISCOS 5.005_02
1N/AAlthough we do suggest that you always build your own Perl from
1N/Athe source code, both for maximal configurability and for security,
1N/Ain case you are in a hurry you can check
1N/AL<perlaix>, L<perlamiga>, L<perlapollo>, L<perlbeos>, L<perlbs2000>,
1N/AL<perlce>, L<perlcygwin>, L<perldgux>, L<perldos>, L<perlepoc>,
1N/AL<perlebcdic>, L<perlfreebsd>, L<perlhurd>, L<perlhpux>, L<perlirix>,
1N/AL<perlmachten>, L<perlmacos>, L<perlmacosx>, L<perlmint>, L<perlmpeix>,
1N/AL<perlnetware>, L<perlos2>, L<perlos390>, L<perlos400>,
1N/AL<perlplan9>, L<perlqnx>, L<perlsolaris>, L<perltru64>,
1N/AL<perlunicode>, L<perlvmesa>, L<perlvms>, L<perlvos>,
1N/AL<perlwin32>, and L<Win32>.
1N/A=head1 AUTHORS / CONTRIBUTORS
1N/AAbigail <abigail@foad.org>,
1N/ACharles Bailey <bailey@newman.upenn.edu>,
1N/AGraham Barr <gbarr@pobox.com>,
1N/ATom Christiansen <tchrist@perl.com>,
1N/ANicholas Clark <nick@ccl4.org>,
1N/AThomas Dorner <Thomas.Dorner@start.de>,
1N/AAndy Dougherty <doughera@lafayette.edu>,
1N/ADominic Dunlop <domo@computer.org>,
1N/ANeale Ferguson <neale@vma.tabnsw.com.au>,
1N/ADavid J. Fiander <davidf@mks.com>,
1N/APaul Green <Paul_Green@stratus.com>,
1N/AJarkko Hietaniemi <jhi@iki.fi>,
1N/ALuther Huffman <lutherh@stratcom.com>,
1N/ANick Ing-Simmons <nick@ing-simmons.net>,
1N/AAndreas J. KE<ouml>nig <a.koenig@mind.de>,
1N/AMarkus Laker <mlaker@contax.co.uk>,
1N/AAndrew M. Langmead <aml@world.std.com>,
1N/ALarry Moore <ljmoore@freespace.net>,
1N/APaul Moore <Paul.Moore@uk.origin-it.com>,
1N/AChris Nandor <pudge@pobox.com>,
1N/AMatthias Neeracher <neeracher@mac.com>,
1N/APhilip Newton <pne@cpan.org>,
1N/AGary Ng <71564.1743@CompuServe.COM>,
1N/ATom Phoenix <rootbeer@teleport.com>,
1N/AAndrE<eacute> Pirard <A.Pirard@ulg.ac.be>,
1N/APeter Prymmer <pvhp@forte.com>,
1N/AHugo van der Sanden <hv@crypt0.demon.co.uk>,
1N/AGurusamy Sarathy <gsar@activestate.com>,
1N/APaul J. Schinder <schinder@pobox.com>,
1N/AMichael G Schwern <schwern@pobox.com>,
1N/ADan Sugalski <dan@sidhe.org>,
1N/ANathan Torkington <gnat@frii.com>.
