perlport.pod

来自「MSYS在windows下模拟了一个类unix的终端」· POD 代码 · 共 1,913 行 · 第 1/5 页

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.

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 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.  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;
    $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 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 little about character sets.  Assume nothing about
numerical values (C<ord>, C<chr>) of characters.  Do not
assume that the alphabetic characters are encoded contiguously (in
the numeric sense).  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.

=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:

    # NOTE: this is no longer "bad" in perl5.005
    for (0..10000000) {}                       # bad
    for (my $x = 0; $x <= 10000000; ++$x) {}   # good

    @lines = <VERY_LARGE_FILE>;                # bad

    while (<FILE>) {$file .= $_}               # sometimes bad
    $file = join('', <FILE>);                  # 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, do
not--unfortunately.  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).

=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 an system call.  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.

=over 4

=item Mailing list: [e-mail]

=item Testing results: http://testers.cpan.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
    dgux          dgux       AViiON-dgux
    DYNIX/ptx     dynixptx   i386-dynixptx
    FreeBSD       freebsd    freebsd-i386    
    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
    MachTen PPC   machten    powerpc-machten
    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:

    $filespec0 = "c:/foo/bar/file.txt";
    $filespec1 = "c:\\foo\\bar\\file.txt";
    $filespec2 = 'c:\foo\bar\file.txt';
    $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'}
    --------------------------------------------
    MS-DOS        dos
    PC-DOS        dos
    OS/2          os2
    Windows 95    MSWin32    MSWin32-x86
    Windows 98    MSWin32    MSWin32-x86
    Windows NT    MSWin32    MSWin32-x86
    Windows NT    MSWin32    MSWin32-ALPHA
    Windows NT    MSWin32    MSWin32-ppc
    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";
    }

Also see:

=over 4

=item *

The djgpp environment for DOS, http://www.delorie.com/djgpp/
and L<perldos>.

=item *

The EMX environment for DOS, OS/2, etc. [e-mail],
http://www.leo.org/pub/comp/os/os2/leo/gnu/emx+gcc/index.html or
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, http://www.activestate.com/

=item *

The Cygwin environment for Win32; F<README.cygwin> (installed 
as L<perlcygwin>), http://www.cygwin.com/

=item *

The U/WIN environment for Win32,
http://www.research.att.com/sw/tools/uwin/

=item *

Build instructions for OS/2, L<perlos2>

=back

=head2 S<Mac OS>

Any module requiring XS compilation is right out for most people, because
MacPerl is built using non-free (and non-cheap!) compilers.  Some XS
modules that can work with MacPerl are built and distributed in binary
form on CPAN.

Directories are specified as:

    volume:folder:file              for absolute pathnames
    volume:folder:                  for absolute pathnames
    :folder:file                    for relative pathnames
    :folder:                        for relative pathnames
    :file                           for relative pathnames
    file                            for relative pathnames

Files are stored in the directory in alphabetical order.  Filenames are
limited to 31 characters, and may include any character except for
null and C<:>, which is reserved as the path separator.

Instead of C<flock>, see C<FSpSetFLock> and C<FSpRstFLock> in the
Mac::Files module, or C<chmod(0444, ...)> and C<chmod(0666, ...)>.

In the MacPerl application, you can't run a program from the command line;
programs that expect C<@ARGV> to be populated can be edited with something
like the following, which brings up a dialog box asking for the command
line arguments.

    if (!@ARGV) {
        @ARGV = split /\s+/, MacPerl::Ask('Arguments?');
    }

A MacPerl script saved as a "droplet" will populate C<@ARGV> with the full
pathnames of the files dropped onto the script.

Mac users can run programs under a type of command line interface