perlport.1

视频监控网络部分的协议ddns,的模块的实现代码,请大家大胆指正.

.PP
This example is preferred over the previous one\*(--even for Unix
platforms\*(--because now any \f(CW\*(C`\e015\*(C'\fR's (\f(CW\*(C`\ecM\*(C'\fR's) are stripped out
(and there was much rejoicing).
.PP
Similarly, functions that return text data\*(--such as a function that
fetches a web page\*(--should sometimes translate newlines before
returning the data, if they've not yet been translated to the local
newline representation.  A single line of code will often suffice:
.PP
.Vb 2
\&    $data =~ s/\e015?\e012/\en/g;
\&    return $data;
.Ve
.PP
Some of this may be confusing.  Here's a handy reference to the \s-1ASCII\s0 \s-1CR\s0
and \s-1LF\s0 characters.  You can print it out and stick it in your wallet.
.PP
.Vb 2
\&    LF  eq  \e012  eq  \ex0A  eq  \ecJ  eq  chr(10)  eq  ASCII 10
\&    CR  eq  \e015  eq  \ex0D  eq  \ecM  eq  chr(13)  eq  ASCII 13
\&
\&             | Unix | DOS  | Mac  |
\&        \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
\&        \en   |  LF  |  LF  |  CR  |
\&        \er   |  CR  |  CR  |  LF  |
\&        \en * |  LF  | CRLF |  CR  |
\&        \er * |  CR  |  CR  |  LF  |
\&        \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
\&        * text\-mode STDIO
.Ve
.PP
The Unix column assumes that you are not accessing a serial line
(like a tty) in canonical mode.  If you are, then \s-1CR\s0 on input becomes
\&\*(L"\en\*(R", and \*(L"\en\*(R" on output becomes \s-1CRLF\s0.
.PP
These are just the most common definitions of \f(CW\*(C`\en\*(C'\fR and \f(CW\*(C`\er\*(C'\fR in Perl.
There may well be others.  For example, on an \s-1EBCDIC\s0 implementation
such as z/OS (\s-1OS/390\s0) or \s-1OS/400\s0 (using the \s-1ILE\s0, the \s-1PASE\s0 is ASCII-based)
the above material is similar to \*(L"Unix\*(R" but the code numbers change:
.PP
.Vb 4
\&    LF  eq  \e025  eq  \ex15  eq  \ecU  eq  chr(21)  eq  CP\-1047 21
\&    LF  eq  \e045  eq  \ex25  eq           chr(37)  eq  CP\-0037 37
\&    CR  eq  \e015  eq  \ex0D  eq  \ecM  eq  chr(13)  eq  CP\-1047 13
\&    CR  eq  \e015  eq  \ex0D  eq  \ecM  eq  chr(13)  eq  CP\-0037 13
\&
\&             | z/OS | OS/400 |
\&        \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
\&        \en   |  LF  |  LF    |
\&        \er   |  CR  |  CR    |
\&        \en * |  LF  |  LF    |
\&        \er * |  CR  |  CR    |
\&        \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
\&        * text\-mode STDIO
.Ve
.Sh "Numbers endianness and Width"
.IX Subsection "Numbers endianness and Width"
Different CPUs store integers and floating point numbers in different
orders (called \fIendianness\fR) and widths (32\-bit and 64\-bit being the
most common today).  This affects your programs when they attempt to transfer
numbers in binary format from one \s-1CPU\s0 architecture to another,
usually either \*(L"live\*(R" via network connection, or by storing the
numbers to secondary storage such as a disk file or tape.
.PP
Conflicting storage orders make utter mess out of the numbers.  If a
little-endian host (Intel, \s-1VAX\s0) stores 0x12345678 (305419896 in
decimal), a big-endian host (Motorola, Sparc, \s-1PA\s0) reads it as
0x78563412 (2018915346 in decimal).  Alpha and \s-1MIPS\s0 can be either:
Digital/Compaq used/uses them in little-endian mode; SGI/Cray uses
them in big-endian mode.  To avoid this problem in network (socket)
connections use the \f(CW\*(C`pack\*(C'\fR and \f(CW\*(C`unpack\*(C'\fR formats \f(CW\*(C`n\*(C'\fR and \f(CW\*(C`N\*(C'\fR, the
\&\*(L"network\*(R" orders.  These are guaranteed to be portable.
.PP
As of perl 5.9.2, you can also use the \f(CW\*(C`>\*(C'\fR and \f(CW\*(C`<\*(C'\fR modifiers
to force big\- or little-endian byte-order.  This is useful if you want
to store signed integers or 64\-bit integers, for example.
.PP
You can explore the endianness of your platform by unpacking a
data structure packed in native format such as:
.PP
.Vb 3
\&    print unpack("h*", pack("s2", 1, 2)), "\en";
\&    # \*(Aq10002000\*(Aq on e.g. Intel x86 or Alpha 21064 in little\-endian mode
\&    # \*(Aq00100020\*(Aq on e.g. Motorola 68040
.Ve
.PP
If you need to distinguish between endian architectures you could use
either of the variables set like so:
.PP
.Vb 2
\&    $is_big_endian   = unpack("h*", pack("s", 1)) =~ /01/;
\&    $is_little_endian = unpack("h*", pack("s", 1)) =~ /^1/;
.Ve
.PP
Differing widths can cause truncation even between platforms of equal
endianness.  The platform of shorter width loses the upper parts of the
number.  There is no good solution for this problem except to avoid
transferring or storing raw binary numbers.
.PP
One can circumnavigate both these problems in two ways.  Either
transfer and store numbers always in text format, instead of raw
binary, or else consider using modules like Data::Dumper (included in
the standard distribution as of Perl 5.005) and Storable (included as
of perl 5.8).  Keeping all data as text significantly simplifies matters.
.PP
The v\-strings are portable only up to v2147483647 (0x7FFFFFFF), that's
how far \s-1EBCDIC\s0, or more precisely UTF-EBCDIC will go.
.Sh "Files and Filesystems"
.IX Subsection "Files and Filesystems"
Most platforms these days structure files in a hierarchical fashion.
So, it is reasonably safe to assume that all platforms support the
notion of a \*(L"path\*(R" to uniquely identify a file on the system.  How
that path is really written, though, differs considerably.
.PP
Although similar, file path specifications differ between Unix,
Windows, Mac\ \s-1OS\s0, \s-1OS/2\s0, \s-1VMS\s0, \s-1VOS\s0, \s-1RISC\s0\ \s-1OS\s0, and probably others.
Unix, for example, is one of the few OSes that has the elegant idea
of a single root directory.
.PP
\&\s-1DOS\s0, \s-1OS/2\s0, \s-1VMS\s0, \s-1VOS\s0, and Windows can work similarly to Unix with \f(CW\*(C`/\*(C'\fR
as path separator, or in their own idiosyncratic ways (such as having
several root directories and various \*(L"unrooted\*(R" device files such \s-1NIL:\s0
and \s-1LPT:\s0).
.PP
Mac\ \s-1OS\s0 uses \f(CW\*(C`:\*(C'\fR as a path separator instead of \f(CW\*(C`/\*(C'\fR.
.PP
The filesystem may support neither hard links (\f(CW\*(C`link\*(C'\fR) nor
symbolic links (\f(CW\*(C`symlink\*(C'\fR, \f(CW\*(C`readlink\*(C'\fR, \f(CW\*(C`lstat\*(C'\fR).
.PP
The filesystem may support neither access timestamp nor change
timestamp (meaning that about the only portable timestamp is the
modification timestamp), or one second granularity of any timestamps
(e.g. the \s-1FAT\s0 filesystem limits the time granularity to two seconds).
.PP
The \*(L"inode change timestamp\*(R" (the \f(CW\*(C`\-C\*(C'\fR filetest) may really be the
\&\*(L"creation timestamp\*(R" (which it is not in \s-1UNIX\s0).
.PP
\&\s-1VOS\s0 perl can emulate Unix filenames with \f(CW\*(C`/\*(C'\fR as path separator.  The
native pathname characters greater-than, less-than, number-sign, and
percent-sign are always accepted.
.PP
\&\s-1RISC\s0\ \s-1OS\s0 perl can emulate Unix filenames with \f(CW\*(C`/\*(C'\fR as path
separator, or go native and use \f(CW\*(C`.\*(C'\fR for path separator and \f(CW\*(C`:\*(C'\fR to
signal filesystems and disk names.
.PP
Don't assume \s-1UNIX\s0 filesystem access semantics: that read, write,
and execute are all the permissions there are, and even if they exist,
that their semantics (for example what do r, w, and x mean on
a directory) are the \s-1UNIX\s0 ones.  The various \s-1UNIX/POSIX\s0 compatibility
layers usually try to make interfaces like \fIchmod()\fR work, but sometimes
there simply is no good mapping.
.PP
If all this is intimidating, have no (well, maybe only a little)
fear.  There are modules that can help.  The File::Spec modules
provide methods to do the Right Thing on whatever platform happens
to be running the program.
.PP
.Vb 6
\&    use File::Spec::Functions;
\&    chdir(updir());        # go up one directory
\&    $file = catfile(curdir(), \*(Aqtemp\*(Aq, \*(Aqfile.txt\*(Aq);
\&    # on Unix and Win32, \*(Aq./temp/file.txt\*(Aq
\&    # on Mac OS, \*(Aq:temp:file.txt\*(Aq
\&    # on VMS, \*(Aq[.temp]file.txt\*(Aq
.Ve
.PP
File::Spec is available in the standard distribution as of version
5.004_05.  File::Spec::Functions is only in File::Spec 0.7 and later,
and some versions of perl come with version 0.6.  If File::Spec
is not updated to 0.7 or later, you must use the object-oriented
interface from File::Spec (or upgrade File::Spec).
.PP
In general, production code should not have file paths hardcoded.
Making them user-supplied or read from a configuration file is
better, keeping in mind that file path syntax varies on different
machines.
.PP
This is especially noticeable in scripts like Makefiles and test suites,
which often assume \f(CW\*(C`/\*(C'\fR as a path separator for subdirectories.
.PP
Also of use is File::Basename from the standard distribution, which
splits a pathname into pieces (base filename, full path to directory,
and file suffix).
.PP
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 \fI/etc/passwd\fR,
\&\fI/etc/sendmail.conf\fR, \fI/etc/resolv.conf\fR, or even \fI/tmp/\fR.  For
example, \fI/etc/passwd\fR 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 \s-1NIS\s0. 
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.
.PP
Don't assume a text file will end with a newline.  They should,
but people forget.
.PP
Do not have two files or directories of the same name with different
case, like \fItest.pl\fR and \fITest.pl\fR, as many platforms have
case-insensitive (or at least case-forgiving) filenames.  Also, try
not to have non-word characters (except for \f(CW\*(C`.\*(C'\fR) in the names, and
keep them to the 8.3 convention, for maximum portability, onerous a
burden though this may appear.
.PP
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.
.PP
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.
.PP
Many systems (\s-1DOS\s0, \s-1VMS\s0 \s-1ODS\-2\s0) cannot have more than one \f(CW\*(C`.\*(C'\fR in their
filenames.
.PP
Don't assume \f(CW\*(C`>\*(C'\fR won't be the first character of a filename.
Always use \f(CW\*(C`<\*(C'\fR 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.
.PP
.Vb 1
\&    open(FILE, \*(Aq<\*(Aq, $existing_file) or die $!;
.Ve
.PP
If filenames might use strange characters, it is safest to open it
with \f(CW\*(C`sysopen\*(C'\fR instead of \f(CW\*(C`open\*(C'\fR.  \f(CW\*(C`open\*(C'\fR is magic and can
translate characters like \f(CW\*(C`>\*(C'\fR, \f(CW\*(C`<\*(C'\fR, and \f(CW\*(C`|\*(C'\fR, 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.
.PP
Don't use \f(CW\*(C`:\*(C'\fR as a part of a filename since many systems use that for
their own semantics (Mac \s-1OS\s0 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 \f(CW\*(C`@\*(C'\fR, \f(CW\*(C`;\*(C'\fR and
\&\f(CW\*(C`|\*(C'\fR.
.PP
Don't assume that in pathnames you can collapse two leading slashes
\&\f(CW\*(C`//\*(C'\fR into one: some networking and clustering filesystems have special
semantics for that.  Let the operating system to sort it out.
.PP
The \fIportable filename characters\fR as defined by \s-1ANSI\s0 C are
.PP
.Vb 4
\& 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
\& . _ \-
.Ve
.PP
and the \*(L"\-\*(R" 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 \f(CW\*(C`.\*(C'\fR, if any, and to three characters after the
\&\f(CW\*(C`.\*(C'\fR, if any).  (And do not use \f(CW\*(C`.\*(C'\fRs in directory names.)
.Sh "System Interaction"
.IX Subsection "System Interaction"
Not all platforms provide a command line.  These are usually platforms
that rely primarily on a Graphical User Interface (\s-1GUI\s0) 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.
.PP
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 \f(CW\*(C`close\*(C'\fR files when you
are done with them.  Don't \f(CW\*(C`unlink\*(C'\fR or \f(CW\*(C`rename\*(C'\fR an open file.  Don't
\&\f(CW\*(C`tie\*(C'\fR or \f(CW\*(C`open\*(C'\fR a file already tied or opened; \f(CW\*(C`untie\*(C'\fR or \f(CW\*(C`close\*(C'\fR
it first.
.PP
Don't open the same file more than once at a time for writing, as some
operating systems put mandatory locks on such files.
.PP
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 (\s-1AFS\s0, \s-1DFS\s0) the permission to add/delete directory entries
is a completely separate permission.