perlport.pod

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

under MPW (Macintosh Programmer's Workshop, a free development
environment from Apple).  MacPerl was first introduced as an MPW
tool, and MPW can be used like a shell:

    perl myscript.plx some arguments

ToolServer is another app from Apple that provides access to MPW tools
from MPW and the MacPerl app, which allows MacPerl programs to use
C<system>, backticks, and piped C<open>.

"S<Mac OS>" is the proper name for the operating system, but the value
in C<$^O> is "MacOS".  To determine architecture, version, or whether
the application or MPW tool version is running, check:

    $is_app    = $MacPerl::Version =~ /App/;
    $is_tool   = $MacPerl::Version =~ /MPW/;
    ($version) = $MacPerl::Version =~ /^(\S+)/;
    $is_ppc    = $MacPerl::Architecture eq 'MacPPC';
    $is_68k    = $MacPerl::Architecture eq 'Mac68K';

S<Mac OS X>, based on NeXT's OpenStep OS, runs MacPerl natively, under the
"Classic" environment.  There is no "Carbon" version of MacPerl to run
under the primary Mac OS X environment.  S<Mac OS X> and its Open Source
version, Darwin, both run Unix perl natively.

Also see:

=over 4

=item *

MacPerl Development, http://dev.macperl.org/ .

=item *

The MacPerl Pages, http://www.macperl.com/ .

=item *

The MacPerl mailing lists, http://lists.perl.org/ .

=back

=head2 VMS

Perl on VMS is discussed in L<perlvms> in the perl distribution.
Perl on VMS can accept either VMS- or Unix-style file
specifications as in either of the following:

    $ perl -ne "print if /perl_setup/i" SYS$LOGIN:LOGIN.COM
    $ perl -ne "print if /perl_setup/i" /sys$login/login.com

but not a mixture of both as in:

    $ perl -ne "print if /perl_setup/i" sys$login:/login.com
    Can't open sys$login:/login.com: file specification syntax error

Interacting with Perl from the Digital Command Language (DCL) shell
often requires a different set of quotation marks than Unix shells do.
For example:

    $ perl -e "print ""Hello, world.\n"""
    Hello, world.

There are several ways to wrap your perl scripts in DCL F<.COM> files, if
you are so inclined.  For example:

    $ write sys$output "Hello from DCL!"
    $ if p1 .eqs. ""
    $ then perl -x 'f$environment("PROCEDURE")
    $ else perl -x - 'p1 'p2 'p3 'p4 'p5 'p6 'p7 'p8
    $ deck/dollars="__END__"
    #!/usr/bin/perl

    print "Hello from Perl!\n";

    __END__
    $ endif

Do take care with C<$ ASSIGN/nolog/user SYS$COMMAND: SYS$INPUT> if your
perl-in-DCL script expects to do things like C<< $read = <STDIN>; >>.

Filenames are in the format "name.extension;version".  The maximum
length for filenames is 39 characters, and the maximum length for
extensions is also 39 characters.  Version is a number from 1 to
32767.  Valid characters are C</[A-Z0-9$_-]/>.

VMS's RMS filesystem is case-insensitive and does not preserve case.
C<readdir> returns lowercased filenames, but specifying a file for
opening remains case-insensitive.  Files without extensions have a
trailing period on them, so doing a C<readdir> with a file named F<A.;5>
will return F<a.> (though that file could be opened with
C<open(FH, 'A')>).

RMS had an eight level limit on directory depths from any rooted logical
(allowing 16 levels overall) prior to VMS 7.2.  Hence
C<PERL_ROOT:[LIB.2.3.4.5.6.7.8]> is a valid directory specification but
C<PERL_ROOT:[LIB.2.3.4.5.6.7.8.9]> is not.  F<Makefile.PL> authors might
have to take this into account, but at least they can refer to the former
as C</PERL_ROOT/lib/2/3/4/5/6/7/8/>.

The VMS::Filespec module, which gets installed as part of the build
process on VMS, is a pure Perl module that can easily be installed on
non-VMS platforms and can be helpful for conversions to and from RMS
native formats.

What C<\n> represents depends on the type of file opened.  It usually
represents C<\012> but it could also be C<\015>, C<\012>, C<\015\012>, 
C<\000>, C<\040>, or nothing depending on the file organiztion and 
record format.  The VMS::Stdio module provides access to the 
special fopen() requirements of files with unusual attributes on VMS.

TCP/IP stacks are optional on VMS, so socket routines might not be
implemented.  UDP sockets may not be supported.

The value of C<$^O> on OpenVMS is "VMS".  To determine the architecture
that you are running on without resorting to loading all of C<%Config>
you can examine the content of the C<@INC> array like so:

    if (grep(/VMS_AXP/, @INC)) {
        print "I'm on Alpha!\n";

    } elsif (grep(/VMS_VAX/, @INC)) {
        print "I'm on VAX!\n";

    } else {
        print "I'm not so sure about where $^O is...\n";
    }

On VMS, perl determines the UTC offset from the C<SYS$TIMEZONE_DIFFERENTIAL>
logical name.  Although the VMS epoch began at 17-NOV-1858 00:00:00.00,
calls to C<localtime> are adjusted to count offsets from
01-JAN-1970 00:00:00.00, just like Unix.

Also see:

=over 4

=item *

F<README.vms> (installed as L<README_vms>), L<perlvms>

=item *

vmsperl list, [e-mail]

(Put the words C<subscribe vmsperl> in message body.)

=item *

vmsperl on the web, http://www.sidhe.org/vmsperl/index.html

=back

=head2 VOS

Perl on VOS is discussed in F<README.vos> in the perl distribution
(installed as L<perlvos>).  Perl on VOS can accept either VOS- or
Unix-style file specifications as in either of the following:

    $ perl -ne "print if /perl_setup/i" >system>notices
    $ perl -ne "print if /perl_setup/i" /system/notices

or even a mixture of both as in:

    $ perl -ne "print if /perl_setup/i" >system/notices

Even though VOS allows the slash character to appear in object
names, because the VOS port of Perl interprets it as a pathname
delimiting character, VOS files, directories, or links whose names
contain a slash character cannot be processed.  Such files must be
renamed before they can be processed by Perl.  Note that VOS limits
file names to 32 or fewer characters.

See F<README.vos> for restrictions that apply when Perl is built
with the alpha version of VOS POSIX.1 support.

Perl on VOS is built without any extensions and does not support
dynamic loading.

The value of C<$^O> on VOS is "VOS".  To determine the architecture that
you are running on without resorting to loading all of C<%Config> you
can examine the content of the @INC array like so:

    if ($^O =~ /VOS/) {
        print "I'm on a Stratus box!\n";
    } else {
        print "I'm not on a Stratus box!\n";
        die;
    }

    if (grep(/860/, @INC)) {
        print "This box is a Stratus XA/R!\n";

    } elsif (grep(/7100/, @INC)) {
        print "This box is a Stratus HP 7100 or 8xxx!\n";

    } elsif (grep(/8000/, @INC)) {
        print "This box is a Stratus HP 8xxx!\n";

    } else {
        print "This box is a Stratus 68K!\n";
    }

Also see:

=over 4

=item *

F<README.vos>

=item *

The VOS mailing list.

There is no specific mailing list for Perl on VOS.  You can post
comments to the comp.sys.stratus newsgroup, or subscribe to the general
Stratus mailing list.  Send a letter with "Subscribe Info-Stratus" in
the message body to [e-mail].

=item *

VOS Perl on the web at http://ftp.stratus.com/pub/vos/vos.html

=back

=head2 EBCDIC Platforms

Recent versions of Perl have been ported to platforms such as OS/400 on
AS/400 minicomputers as well as OS/390, VM/ESA, and BS2000 for S/390
Mainframes.  Such computers use EBCDIC character sets internally (usually
Character Code Set ID 0037 for OS/400 and either 1047 or POSIX-BC for S/390
systems).  On the mainframe perl currently works under the "Unix system
services for OS/390" (formerly known as OpenEdition), VM/ESA OpenEdition, or
the BS200 POSIX-BC system (BS2000 is supported in perl 5.6 and greater).
See L<perlos390> for details.  

As of R2.5 of USS for OS/390 and Version 2.3 of VM/ESA these Unix
sub-systems do not support the C<#!> shebang trick for script invocation.
Hence, on OS/390 and VM/ESA perl scripts can be executed with a header
similar to the following simple script:

    : # use perl
        eval 'exec /usr/local/bin/perl -S $0 ${1+"$@"}'
            if 0;
    #!/usr/local/bin/perl     # just a comment really

    print "Hello from perl!\n";

OS/390 will support the C<#!> shebang trick in release 2.8 and beyond.
Calls to C<system> and backticks can use POSIX shell syntax on all
S/390 systems.

On the AS/400, if PERL5 is in your library list, you may need
to wrap your perl scripts in a CL procedure to invoke them like so:

    BEGIN
      CALL PGM(PERL5/PERL) PARM('/QOpenSys/hello.pl')
    ENDPGM

This will invoke the perl script F<hello.pl> in the root of the
QOpenSys file system.  On the AS/400 calls to C<system> or backticks
must use CL syntax.

On these platforms, bear in mind that the EBCDIC character set may have
an effect on what happens with some perl functions (such as C<chr>,
C<pack>, C<print>, C<printf>, C<ord>, C<sort>, C<sprintf>, C<unpack>), as
well as bit-fiddling with ASCII constants using operators like C<^>, C<&>
and C<|>, not to mention dealing with socket interfaces to ASCII computers
(see L<"Newlines">).

Fortunately, most web servers for the mainframe will correctly
translate the C<\n> in the following statement to its ASCII equivalent
(C<\r> is the same under both Unix and OS/390 & VM/ESA):

    print "Content-type: text/html\r\n\r\n";

The values of C<$^O> on some of these platforms includes:

    uname         $^O        $Config{'archname'}
    --------------------------------------------
    OS/390        os390      os390
    OS400         os400      os400
    POSIX-BC      posix-bc   BS2000-posix-bc
    VM/ESA        vmesa      vmesa

Some simple tricks for determining if you are running on an EBCDIC
platform could include any of the following (perhaps all):

    if ("\t" eq "\05")   { print "EBCDIC may be spoken here!\n"; }

    if (ord('A') == 193) { print "EBCDIC may be spoken here!\n"; }

    if (chr(169) eq 'z') { print "EBCDIC may be spoken here!\n"; }

One thing you may not want to rely on is the EBCDIC encoding
of punctuation characters since these may differ from code page to code
page (and once your module or script is rumoured to work with EBCDIC,
folks will want it to work with all EBCDIC character sets).

Also see:

=over 4

=item *

*

L<perlos390>, F<README.os390>, F<perlbs2000>, F<README.vmesa>,
L<perlebcdic>.

=item *

The [e-mail] list is for discussion of porting issues as well as
general usage issues for all EBCDIC Perls.  Send a message body of
"subscribe perl-mvs" to [e-mail].

=item  *

AS/400 Perl information at
http://as400.rochester.ibm.com/
as well as on CPAN in the F<ports/> directory.

=back

=head2 Acorn RISC OS

Because Acorns use ASCII with newlines (C<\n>) in text files as C<\012> like
Unix, and because Unix filename emulation is turned on by default, 
most simple scripts will probably work "out of the box".  The native
filesystem is modular, and individual filesystems are free to be
case-sensitive or insensitive, and are usually case-preserving.  Some
native filesystems have name length limits, which file and directory
names are silently truncated to fit.  Scripts should be aware that the
standard filesystem currently has a name length limit of B<10>
characters, with up to 77 items in a directory, but other filesystems
may not impose such limitations.

Native filenames are of the form

    Filesystem#Special_Field::DiskName.$.Directory.Directory.File

where

    Special_Field is not usually present, but may contain . and $ .
    Filesystem =~ m|[A-Za-z0-9_]|
    DsicName   =~ m|[A-Za-z0-9_/]|
    $ represents the root directory
    . is the path separator
    @ is the current directory (per filesystem but machine global)
    ^ is the parent directory
    Directory and File =~ m|[^\0- "\.\$\%\&:\@\\^\|\177]+|

The default filename translation is roughly C<tr|/.|./|;>

Note that C<"ADFS::HardDisk.$.File" ne 'ADFS::HardDisk.$.File'> and that
the second stage of C<$> interpolation in regular expressions will fall
foul of the C<$.> if scripts are not careful.

Logical paths specified by system variables containing comma-separated
search lists are also allowed; hence C<System:Modules> is a valid
filename, and the filesystem will prefix C<Modules> with each section of
C<System$Path> until a name is made that points to an object on disk.
Writing to a new file C<System:Modules> would be allowed only if
C<System$Path> contains a single item list.  The filesystem will also
expand system variables in filenames if enclosed in angle brackets, so
C<< <System$Dir>.Modules >> would look for the file
S<C<$ENV{'System$Dir'} . 'Modules'>>.  The obvious implication of this is
that B<fully qualified filenames can start with C<< <> >>> and should
be protected when C<open> is used for input.

Because C<.> was in use as a directory separator and filenames could not
be assumed to be unique after 10 characters, Acorn implemented the C
compiler to strip the trailing C<.c> C<.h> C<.s> and C<.o> suffix from
filenames specified in source code and store the respective files in
subdirectories named after the suffix.  Hence files are translated:

    foo.h           h.foo
    C:foo.h         C:h.foo        (logical path variable)
    sys/os.h        sys.h.os       (C compiler groks Unix-speak)
    10charname.c    c.10charname
    10charname.o    o.10charname