perlport.pod

来自「视频监控网络部分的协议ddns,的模块的实现代码,请大家大胆指正.」· POD 代码 · 共 1,586 行 · 第 1/5 页

and file suffix).

Even when on a single platform (if you can call Unix a single platform),
remember not to count on the existence or the contents of particular
system-specific files or directories, like F</etc/passwd>,
F</etc/sendmail.conf>, F</etc/resolv.conf>, or even F</tmp/>.  For
example, F</etc/passwd> may exist but not contain the encrypted
passwords, because the system is using some form of enhanced security.
Or it may not contain all the accounts, because the system is using NIS. 
If code does need to rely on such a file, include a description of the
file and its format in the code's documentation, then make it easy for
the user to override the default location of the file.

Don't assume a text file will end with a newline.  They should,
but people forget.

Do not have two files or directories of the same name with different
case, like F<test.pl> and F<Test.pl>, as many platforms have
case-insensitive (or at least case-forgiving) filenames.  Also, try
not to have non-word characters (except for C<.>) in the names, and
keep them to the 8.3 convention, for maximum portability, onerous a
burden though this may appear.

Likewise, when using the AutoSplit module, try to keep your functions to
8.3 naming and case-insensitive conventions; or, at the least,
make it so the resulting files have a unique (case-insensitively)
first 8 characters.

Whitespace in filenames is tolerated on most systems, but not all,
and even on systems where it might be tolerated, some utilities
might become confused by such whitespace.

Many systems (DOS, VMS ODS-2) cannot have more than one C<.> in their
filenames.

Don't assume C<< > >> won't be the first character of a filename.
Always use C<< < >> explicitly to open a file for reading, or even
better, use the three-arg version of open, unless you want the user to
be able to specify a pipe open.

    open(FILE, '<', $existing_file) or die $!;

If filenames might use strange characters, it is safest to open it
with C<sysopen> instead of C<open>.  C<open> is magic and can
translate characters like C<< > >>, C<< < >>, and C<|>, which may
be the wrong thing to do.  (Sometimes, though, it's the right thing.)
Three-arg open can also help protect against this translation in cases
where it is undesirable.

Don't use C<:> as a part of a filename since many systems use that for
their own semantics (Mac OS Classic for separating pathname components,
many networking schemes and utilities for separating the nodename and
the pathname, and so on).  For the same reasons, avoid C<@>, C<;> and
C<|>.

Don't assume that in pathnames you can collapse two leading slashes
C<//> into one: some networking and clustering filesystems have special
semantics for that.  Let the operating system to sort it out.

The I<portable filename characters> as defined by ANSI C are

 a b c d e f g h i j k l m n o p q r t u v w x y z
 A B C D E F G H I J K L M N O P Q R T U V W X Y Z
 0 1 2 3 4 5 6 7 8 9
 . _ -

and the "-" shouldn't be the first character.  If you want to be
hypercorrect, stay case-insensitive and within the 8.3 naming
convention (all the files and directories have to be unique within one
directory if their names are lowercased and truncated to eight
characters before the C<.>, if any, and to three characters after the
C<.>, if any).  (And do not use C<.>s in directory names.)

=head2 System Interaction

Not all platforms provide a command line.  These are usually platforms
that rely primarily on a Graphical User Interface (GUI) for user
interaction.  A program requiring a command line interface might
not work everywhere.  This is probably for the user of the program
to deal with, so don't stay up late worrying about it.

Some platforms can't delete or rename files held open by the system,
this limitation may also apply to changing filesystem metainformation
like file permissions or owners.  Remember to C<close> files when you
are done with them.  Don't C<unlink> or C<rename> an open file.  Don't
C<tie> or C<open> a file already tied or opened; C<untie> or C<close>
it first.

Don't open the same file more than once at a time for writing, as some
operating systems put mandatory locks on such files.

Don't assume that write/modify permission on a directory gives the
right to add or delete files/directories in that directory.  That is
filesystem specific: in some filesystems you need write/modify
permission also (or even just) in the file/directory itself.  In some
filesystems (AFS, DFS) the permission to add/delete directory entries
is a completely separate permission.

Don't assume that a single C<unlink> completely gets rid of the file:
some filesystems (most notably the ones in VMS) have versioned
filesystems, and unlink() removes only the most recent one (it doesn't
remove all the versions because by default the native tools on those
platforms remove just the most recent version, too).  The portable
idiom to remove all the versions of a file is

    1 while unlink "file";

This will terminate if the file is undeleteable for some reason
(protected, not there, and so on).

Don't count on a specific environment variable existing in C<%ENV>.
Don't count on C<%ENV> entries being case-sensitive, or even
case-preserving.  Don't try to clear %ENV by saying C<%ENV = ();>, or,
if you really have to, make it conditional on C<$^O ne 'VMS'> since in
VMS the C<%ENV> table is much more than a per-process key-value string
table.

On VMS, some entries in the %ENV hash are dynamically created when
their key is used on a read if they did not previously exist.  The
values for C<$ENV{HOME}>, C<$ENV{TERM}>, C<$ENV{HOME}>, and C<$ENV{USER}>,
are known to be dynamically generated.  The specific names that are
dynamically generated may vary with the version of the C library on VMS,
and more may exist than is documented.

On VMS by default, changes to the %ENV hash are persistent after the process
exits.  This can cause unintended issues.

Don't count on signals or C<%SIG> for anything.

Don't count on filename globbing.  Use C<opendir>, C<readdir>, and
C<closedir> instead.

Don't count on per-program environment variables, or per-program current
directories.

Don't count on specific values of C<$!>, neither numeric nor
especially the strings values-- users may switch their locales causing
error messages to be translated into their languages.  If you can
trust a POSIXish environment, you can portably use the symbols defined
by the Errno module, like ENOENT.  And don't trust on the values of C<$!>
at all except immediately after a failed system call.

=head2 Command names versus file pathnames

Don't assume that the name used to invoke a command or program with
C<system> or C<exec> can also be used to test for the existence of the
file that holds the executable code for that command or program.
First, many systems have "internal" commands that are built-in to the
shell or OS and while these commands can be invoked, there is no
corresponding file.  Second, some operating systems (e.g., Cygwin,
DJGPP, OS/2, and VOS) have required suffixes for executable files;
these suffixes are generally permitted on the command name but are not
required.  Thus, a command like "perl" might exist in a file named
"perl", "perl.exe", or "perl.pm", depending on the operating system.
The variable "_exe" in the Config module holds the executable suffix,
if any.  Third, the VMS port carefully sets up $^X and
$Config{perlpath} so that no further processing is required.  This is
just as well, because the matching regular expression used below would
then have to deal with a possible trailing version number in the VMS
file name.

To convert $^X to a file pathname, taking account of the requirements
of the various operating system possibilities, say:

  use Config;
  $thisperl = $^X;
  if ($^O ne 'VMS')
     {$thisperl .= $Config{_exe} unless $thisperl =~ m/$Config{_exe}$/i;}

To convert $Config{perlpath} to a file pathname, say:

  use Config;
  $thisperl = $Config{perlpath};
  if ($^O ne 'VMS')
     {$thisperl .= $Config{_exe} unless $thisperl =~ m/$Config{_exe}$/i;}

=head2 Networking

Don't assume that you can reach the public Internet.

Don't assume that there is only one way to get through firewalls
to the public Internet.

Don't assume that you can reach outside world through any other port
than 80, or some web proxy.  ftp is blocked by many firewalls.

Don't assume that you can send email by connecting to the local SMTP port.

Don't assume that you can reach yourself or any node by the name
'localhost'.  The same goes for '127.0.0.1'.  You will have to try both.

Don't assume that the host has only one network card, or that it
can't bind to many virtual IP addresses.

Don't assume a particular network device name.

Don't assume a particular set of ioctl()s will work.

Don't assume that you can ping hosts and get replies.

Don't assume that any particular port (service) will respond.

Don't assume that Sys::Hostname (or any other API or command)
returns either a fully qualified hostname or a non-qualified hostname:
it all depends on how the system had been configured.  Also remember
things like DHCP and NAT-- the hostname you get back might not be very
useful.

All the above "don't":s may look daunting, and they are -- but the key
is to degrade gracefully if one cannot reach the particular network
service one wants.  Croaking or hanging do not look very professional.

=head2 Interprocess Communication (IPC)

In general, don't directly access the system in code meant to be
portable.  That means, no C<system>, C<exec>, C<fork>, C<pipe>,
C<``>, C<qx//>, C<open> with a C<|>, nor any of the other things
that makes being a perl hacker worth being.

Commands that launch external processes are generally supported on
most platforms (though many of them do not support any type of
forking).  The problem with using them arises from what you invoke
them on.  External tools are often named differently on different
platforms, may not be available in the same location, might accept
different arguments, can behave differently, and often present their
results in a platform-dependent way.  Thus, you should seldom depend
on them to produce consistent results. (Then again, if you're calling 
I<netstat -a>, you probably don't expect it to run on both Unix and CP/M.)

One especially common bit of Perl code is opening a pipe to B<sendmail>:

    open(MAIL, '|/usr/lib/sendmail -t') 
	or die "cannot fork sendmail: $!";

This is fine for systems programming when sendmail is known to be
available.  But it is not fine for many non-Unix systems, and even
some Unix systems that may not have sendmail installed.  If a portable
solution is needed, see the various distributions on CPAN that deal
with it.  Mail::Mailer and Mail::Send in the MailTools distribution are
commonly used, and provide several mailing methods, including mail,
sendmail, and direct SMTP (via Net::SMTP) if a mail transfer agent is
not available.  Mail::Sendmail is a standalone module that provides
simple, platform-independent mailing.

The Unix System V IPC (C<msg*(), sem*(), shm*()>) is not available
even on all Unix platforms.

Do not use either the bare result of C<pack("N", 10, 20, 30, 40)> or
bare v-strings (such as C<v10.20.30.40>) to represent IPv4 addresses:
both forms just pack the four bytes into network order.  That this
would be equal to the C language C<in_addr> struct (which is what the
socket code internally uses) is not guaranteed.  To be portable use
the routines of the Socket extension, such as C<inet_aton()>,
C<inet_ntoa()>, and C<sockaddr_in()>.

The rule of thumb for portable code is: Do it all in portable Perl, or
use a module (that may internally implement it with platform-specific
code, but expose a common interface).

=head2 External Subroutines (XS)

XS code can usually be made to work with any platform, but dependent
libraries, header files, etc., might not be readily available or
portable, or the XS code itself might be platform-specific, just as Perl
code might be.  If the libraries and headers are portable, then it is
normally reasonable to make sure the XS code is portable, too.

A different type of portability issue arises when writing XS code:
availability of a C compiler on the end-user's system.  C brings
with it its own portability issues, and writing XS code will expose
you to some of those.  Writing purely in Perl is an easier way to
achieve portability.

=head2 Standard Modules

In general, the standard modules work across platforms.  Notable
exceptions are the CPAN module (which currently makes connections to external
programs that may not be available), platform-specific modules (like
ExtUtils::MM_VMS), and DBM modules.

There is no one DBM module available on all platforms.
SDBM_File and the others are generally available on all Unix and DOSish
ports, but not in MacPerl, where only NBDM_File and DB_File are
available.

The good news is that at least some DBM module should be available, and
AnyDBM_File will use whichever module it can find.  Of course, then
the code needs to be fairly strict, dropping to the greatest common
factor (e.g., not exceeding 1K for each record), so that it will
work with any DBM module.  See L<AnyDBM_File> for more details.

=head2 Time and Date

The system's notion of time of day and calendar date is controlled in
widely different ways.  Don't assume the timezone is stored in C<$ENV{TZ}>,
and even if it is, don't assume that you can control the timezone through
that variable.  Don't assume anything about the three-letter timezone
abbreviations (for example that MST would be the Mountain Standard Time,
it's been known to stand for Moscow Standard Time).  If you need to
use timezones, express them in some unambiguous format like the
exact number of minutes offset from UTC, or the POSIX timezone
format.

Don't assume that the epoch starts at 00:00:00, January 1, 1970,
because that is OS- and implementation-specific.  It is better to
store a date in an unambiguous representation.  The ISO 8601 standard
defines YYYY-MM-DD as the date format, or YYYY-MM-DDTHH-MM-SS
(that's a literal "T" separating the date from the time).
Please do use the ISO 8601 instead of making us to guess what
date 02/03/04 might be.  ISO 8601 even sorts nicely as-is.
A text representation (like "1987-12-18") can be easily converted
into an OS-specific value using a module like Date::Parse.
An array of values, such as those returned by C<localtime>, can be
converted to an OS-specific representation using Time::Local.

When calculating specific times, such as for tests in time or date modules,
it may be appropriate to calculate an offset for the epoch.