transient information about idiosyncrasies of some of the ports, almost
all of which are in a state of constant evolution. Thus, this material
should be considered a perpetual work in progress
-(E<lt>IMG SRC="yellow_sign.gif" ALT="Under Construction"E<gt>).
+(<IMG SRC="yellow_sign.gif" ALT="Under Construction">).
=head1 ISSUES
Whitespace in filenames is tolerated on most systems, but not all.
Many systems (DOS, VMS) cannot have more than one C<.> in their filenames.
-Don't assume C<E<gt>> won't be the first character of a filename.
-Always use C<E<lt>> explicitly to open a file for reading,
+Don't assume C<< > >> won't be the first character of a filename.
+Always use C<< < >> explicitly to open a file for reading,
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<E<gt>>, C<E<lt>>, and C<|>, which may
+translate characters like C<< > >>, C<< < >>, and C<|>, which may
be the wrong thing to do. (Sometimes, though, it's the right thing.)
=head2 System Interaction
=item Mailing list: cpan-testers@perl.org
-=item Testing results: C<http://www.perl.org/cpan-testers/>
+=item Testing results: C<http://testers.cpan.org/>
=back
$ 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 = E<lt>STDINE<gt>;>.
+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
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<E<lt>System$DirE<gt>.Modules> would look for the file
+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<E<lt>E<gt>>> and should
+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
passing C<STDIN>, C<STDOUT>, or C<STDERR> to your children.
The desire of users to express filenames of the form
-C<E<lt>Foo$DirE<gt>.Bar> on the command line unquoted causes problems,
+C<< <Foo$Dir>.Bar >> on the command line unquoted causes problems,
too: C<``> command output capture has to perform a guessing game. It
-assumes that a string C<E<lt>[^E<lt>E<gt>]+\$[^E<lt>E<gt>]E<gt>> is a
+assumes that a string C<< <[^<>]+\$[^<>]> >> is a
reference to an environment variable, whereas anything else involving
-C<E<lt>> or C<E<gt>> is redirection, and generally manages to be 99%
+C<< < >> or C<< > >> is redirection, and generally manages to be 99%
right. Of course, the problem remains that scripts cannot rely on any
Unix tools being available, or that any tools found have Unix-like command
line arguments.
Implemented via Spawn. (VM/ESA)
+Does not automatically flush output handles on some platforms.
+(SunOS, Solaris, HP-UX)
+
=item fcntl FILEHANDLE,FUNCTION,SCALAR
Not implemented. (Win32, VMS)
=item fork
-Not implemented. (S<Mac OS>, Win32, AmigaOS, S<RISC OS>, VOS, VM/ESA)
+Not implemented. (S<Mac OS>, AmigaOS, S<RISC OS>, VOS, VM/ESA)
+
+Emulated using multiple interpreters. See L<perlfork>. (Win32)
+
+Does not automatically flush output handles on some platforms.
+(SunOS, Solaris, HP-UX)
=item getlogin
Not implemented, hence not useful for taint checking. (S<Mac OS>,
S<RISC OS>)
-Unlike Unix platforms, C<kill(0, $pid)> will actually terminate
-the process. (Win32)
+C<kill($sig, $pid)> makes the process exit immediately with exit
+status $sig. As in Unix, if $sig is 0 and the specified process exists,
+it returns true without actually terminating it. (Win32)
=item link OLDFILE,NEWFILE
The C<|> variants are supported only if ToolServer is installed.
(S<Mac OS>)
-open to C<|E<45>> and C<-|> are unsupported. (S<Mac OS>, Win32, S<RISC OS>)
+open to C<|-> and C<-|> are unsupported. (S<Mac OS>, Win32, S<RISC OS>)
+
+Opening a process does not automatically flush output handles on some
+platforms. (SunOS, Solaris, HP-UX)
=item pipe READHANDLE,WRITEHANDLE
There is no shell to process metacharacters, and the native standard is
to pass a command line terminated by "\n" "\r" or "\0" to the spawned
-program. Redirection such as C<E<gt> foo> is performed (if at all) by
+program. Redirection such as C<< > foo >> is performed (if at all) by
the run time library of the spawned program. C<system> I<list> will call
the Unix emulation library's C<exec> emulation, which attempts to provide
emulation of the stdin, stdout, stderr in force in the parent, providing
Far from being POSIX compliant. Because there may be no underlying
/bin/sh tries to work around the problem by forking and execing the
first token in its argument string. Handles basic redirection
-("E<lt>" or "E<gt>") on its own behalf. (MiNT)
+("<" or ">") on its own behalf. (MiNT)
+
+Does not automatically flush output handles on some platforms.
+(SunOS, Solaris, HP-UX)
=item times
=back
+=head1 Supported Platforms
+
+As of early March 2000 (the Perl release 5.6.0), the following
+platforms are able to build Perl from the standard source code
+distribution available at http://www.perl.com/CPAN/src/index.html
+
+ AIX
+ DOS DJGPP 1)
+ FreeBSD
+ HP-UX
+ IRIX
+ Linux
+ LynxOS
+ MachTen
+ MPE/iX
+ NetBSD
+ OpenBSD
+ OS/2
+ QNX
+ Rhapsody/Darwin 2)
+ Solaris
+ SVR4
+ Tru64 UNIX 3)
+ UNICOS
+ UNICOS/mk
+ Unixware
+ VMS
+ VOS
+ Windows 3.1 1)
+ Windows 95 1) 4)
+ Windows 98 1) 4)
+ Windows NT 1) 4)
+
+ 1) in DOS mode either the DOS or OS/2 ports can be used
+ 2) new in 5.6.0: the BSD/NeXT-based UNIX of Mac OS X
+ 3) formerly known as Digital UNIX and before that DEC OSF/1
+ 4) compilers: Borland, Cygwin, Mingw32 EGCS/GCC, VC++
+
+The following platforms worked for the previous major release
+(5.005_03 being the latest maintenance release of that, as of early
+March 2000), but be did not manage to test these in time for the 5.6.0
+release of Perl. There is a very good chance that these will work
+just fine with 5.6.0.
+
+ A/UX
+ BeOS
+ BSD/OS
+ DG/UX
+ DYNIX/ptx
+ DomainOS
+ Hurd
+ NextSTEP
+ OpenSTEP
+ PowerMAX
+ SCO ODT/OSR
+ SunOS
+ Ultrix
+
+The following platform worked for the previous major release (5.005_03
+being the latest maintenance release of that, as of early March 2000).
+However, standardization on UTF-8 as the internal string representation
+in 5.6.0 has introduced incompatibilities in this EBCDIC platform.
+Support for this platform may be enabled in a future release:
+
+ OS390 1)
+
+ 1) Previously known as MVS, or OpenEdition MVS.
+
+Strongly related to the OS390 platform by also being EBCDIC-based
+mainframe platforms are the following platforms:
+
+ BS2000
+ VM/ESA
+
+These are also not expected to work under 5.6.0 for the same reasons
+as OS390. Contact the mailing list perl-mvs@perl.org for more details.
+
+MacOS (Classic, pre-X) is almost 5.6.0-ready; building from the source
+does work with 5.6.0, but additional MacOS specific source code is needed
+for a complete port. Contact the mailing list macperl-porters@macperl.org
+for more information.
+
+The following platforms have been known to build Perl from source in
+the past, but we haven't been able to verify their status for the
+current release, either because the hardware/software platforms are
+rare or because we don't have an active champion on these
+platforms--or both:
+
+ 3b1
+ AmigaOS
+ ConvexOS
+ CX/UX
+ DC/OSx
+ DDE SMES
+ DOS EMX
+ Dynix
+ EP/IX
+ ESIX
+ FPS
+ GENIX
+ Greenhills
+ ISC
+ MachTen 68k
+ MiNT
+ MPC
+ NEWS-OS
+ Opus
+ Plan 9
+ PowerUX
+ RISC/os
+ Stellar
+ SVR2
+ TI1500
+ TitanOS
+ Unisys Dynix
+ Unixware
+
+Support for the following platform is planned for a future Perl release:
+
+ Netware
+
+The following platforms have their own source code distributions and
+binaries available via http://www.perl.com/CPAN/ports/index.html:
+
+ Perl release
+
+ AS/400 5.003
+ Netware 5.003_07
+ Tandem Guardian 5.004
+
+The following platforms have only binaries available via
+http://www.perl.com/CPAN/ports/index.html:
+
+ Perl release
+
+ Acorn RISCOS 5.005_02
+ AOS 5.002
+ LynxOS 5.004_02
+
+Although we do suggest that you always build your own Perl from
+the source code, both for maximal configurability and for security,
+in case you are in a hurry you can check
+http://www.perl.com/CPAN/ports/index.html for binary distributions.
+
=head1 AUTHORS / CONTRIBUTORS
-Abigail E<lt>abigail@fnx.comE<gt>,
-Charles Bailey E<lt>bailey@newman.upenn.eduE<gt>,
-Graham Barr E<lt>gbarr@pobox.comE<gt>,
-Tom Christiansen E<lt>tchrist@perl.comE<gt>,
-Nicholas Clark E<lt>Nicholas.Clark@liverpool.ac.ukE<gt>,
-Thomas Dorner E<lt>Thomas.Dorner@start.deE<gt>,
-Andy Dougherty E<lt>doughera@lafcol.lafayette.eduE<gt>,
-Dominic Dunlop E<lt>domo@vo.luE<gt>,
-Neale Ferguson E<lt>neale@mailbox.tabnsw.com.auE<gt>,
-David J. Fiander E<lt>davidf@mks.comE<gt>,
-Paul Green E<lt>Paul_Green@stratus.comE<gt>,
-M.J.T. Guy E<lt>mjtg@cus.cam.ac.ukE<gt>,
-Jarkko Hietaniemi E<lt>jhi@iki.fi<gt>,
-Luther Huffman E<lt>lutherh@stratcom.comE<gt>,
-Nick Ing-Simmons E<lt>nick@ni-s.u-net.comE<gt>,
-Andreas J. KE<ouml>nig E<lt>koenig@kulturbox.deE<gt>,
-Markus Laker E<lt>mlaker@contax.co.ukE<gt>,
-Andrew M. Langmead E<lt>aml@world.std.comE<gt>,
-Larry Moore E<lt>ljmoore@freespace.netE<gt>,
-Paul Moore E<lt>Paul.Moore@uk.origin-it.comE<gt>,
-Chris Nandor E<lt>pudge@pobox.comE<gt>,
-Matthias Neeracher E<lt>neeri@iis.ee.ethz.chE<gt>,
-Gary Ng E<lt>71564.1743@CompuServe.COME<gt>,
-Tom Phoenix E<lt>rootbeer@teleport.comE<gt>,
-AndrE<eacute> Pirard E<lt>A.Pirard@ulg.ac.beE<gt>,
-Peter Prymmer E<lt>pvhp@forte.comE<gt>,
-Hugo van der Sanden E<lt>hv@crypt0.demon.co.ukE<gt>,
-Gurusamy Sarathy E<lt>gsar@activestate.comE<gt>,
-Paul J. Schinder E<lt>schinder@pobox.comE<gt>,
-Michael G Schwern E<lt>schwern@pobox.comE<gt>,
-Dan Sugalski E<lt>sugalskd@ous.eduE<gt>,
-Nathan Torkington E<lt>gnat@frii.comE<gt>.
+Abigail <abigail@fnx.com>,
+Charles Bailey <bailey@newman.upenn.edu>,
+Graham Barr <gbarr@pobox.com>,
+Tom Christiansen <tchrist@perl.com>,
+Nicholas Clark <Nicholas.Clark@liverpool.ac.uk>,
+Thomas Dorner <Thomas.Dorner@start.de>,
+Andy Dougherty <doughera@lafcol.lafayette.edu>,
+Dominic Dunlop <domo@vo.lu>,
+Neale Ferguson <neale@mailbox.tabnsw.com.au>,
+David J. Fiander <davidf@mks.com>,
+Paul Green <Paul_Green@stratus.com>,
+M.J.T. Guy <mjtg@cus.cam.ac.uk>,
+Jarkko Hietaniemi <jhi@iki.fi<gt>,
+Luther Huffman <lutherh@stratcom.com>,
+Nick Ing-Simmons <nick@ni-s.u-net.com>,
+Andreas J. KE<ouml>nig <koenig@kulturbox.de>,
+Markus Laker <mlaker@contax.co.uk>,
+Andrew M. Langmead <aml@world.std.com>,
+Larry Moore <ljmoore@freespace.net>,
+Paul Moore <Paul.Moore@uk.origin-it.com>,
+Chris Nandor <pudge@pobox.com>,
+Matthias Neeracher <neeri@iis.ee.ethz.ch>,
+Gary Ng <71564.1743@CompuServe.COM>,
+Tom Phoenix <rootbeer@teleport.com>,
+AndrE<eacute> Pirard <A.Pirard@ulg.ac.be>,
+Peter Prymmer <pvhp@forte.com>,
+Hugo van der Sanden <hv@crypt0.demon.co.uk>,
+Gurusamy Sarathy <gsar@activestate.com>,
+Paul J. Schinder <schinder@pobox.com>,
+Michael G Schwern <schwern@pobox.com>,
+Dan Sugalski <sugalskd@ous.edu>,
+Nathan Torkington <gnat@frii.com>.
This document is maintained by Chris Nandor
-E<lt>pudge@pobox.comE<gt>.
+<pudge@pobox.com>.
=head1 VERSION
projects / p5sagit/p5-mst-13.2.git / blobdiff