perlport 1.32

	Message-Id: <v04011701b1ee58b86c63@[192.168.0.3]>

p4raw-id: //depot/maint-5.005/perl@1744

diff --git a/pod/perlport.pod b/pod/perlport.pod
index 63fee2f..3c1fba6 100644 (file)
--- a/pod/perlport.pod
+++ b/pod/perlport.pod
@@ -140,7 +140,7 @@ platforms, because now any C<\015>'s (C<\cM>'s) are stripped out
 (and there was much rejoicing).
 
 
-=head2 File Paths
+=head2 Files
 
 Most platforms these days structure files in a hierarchical fashion.
 So, it is reasonably safe to assume that any platform supports the
@@ -148,7 +148,7 @@ notion of a "path" to uniquely identify a file on the system.  Just
 how that path is actually written, differs.
 
 While they are similar, file path specifications differ between Unix,
-Windows, S<Mac OS>, OS/2, VMS, S<RISC OS> and probably others.  Unix, 
+Windows, S<Mac OS>, OS/2, VMS, S<RISC OS> and probably others.  Unix,
 for example, is one of the few OSes that has the idea of a root directory.
 S<Mac OS> uses C<:> as a path separator instead of C</>.  VMS, Windows, and
 OS/2 can work similarly to Unix with C</> as path separator, or in their own
@@ -191,6 +191,16 @@ Don't assume that a you can open a full pathname for input with
 C<open (FILE, $name)>, as some platforms can use characters such as C<E<lt>>
 which will perl C<open> will interpret and eat.
 
+Do not have two files of the same name with different case, like
+F<test.pl> and <Test.pl>, as many platforms have case-insensitive
+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.
+
+Likewise, if using C<AutoSplit>, try to keep the split functions to
+8.3 naming and case-insensitive conventions; or, at the very least,
+make it so the resulting files have a unique (case-insensitively)
+first 8 characters.
+
 
 =head2 System Interaction
 
@@ -215,7 +225,7 @@ 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
-directores.
+directories.
 
 
 =head2 Interprocess Communication (IPC)
@@ -462,7 +472,7 @@ C<http://www.juge.com/bbs/Hobb.19.html>
 =back
 
 
-=head2 MacPerl
+=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
@@ -518,6 +528,9 @@ the application or MPW tool version is running, check:
     $is_ppc    = $MacPerl::Architecture eq 'MacPPC';
     $is_68k    = $MacPerl::Architecture eq 'Mac68K';
 
+S<Mac OS X>, to be based on NeXT's OpenStep OS, will be able to run MacPerl
+natively (in the Blue Box, and even in the Yellow Box, once some changes
+to the toolbox calls are made), but Unix perl will also run natively.
 
 Also see:
 
@@ -581,10 +594,10 @@ 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 
+(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 C<VMS::Filespec> module, which gets installed as part
@@ -706,7 +719,7 @@ but other filing systems may not impose such limitations.
 Native filenames are of the form
 
     Filesystem#Special_Field::DiscName.$.Directory.Directory.File
-    
+
 where
 
     Special_Field is not usually present, but may contain . and $ .
@@ -786,8 +799,8 @@ obscure and somewhat broken convention.  All this is further complicated by
 the desire of users to express filenames of the form C<E<lt>Foo$DirE<gt>.Bar> on
 the command line unquoted.  (Oh yes, it's run time libraries interpreting the
 quoting convention.)  Hence C<``> command output capture has to perform
-a guessing game as to how the command is going to interpret the command line 
-so that it can bodge it correctly to capture output.  It assumes that a 
+a guessing game as to how the command is going to interpret the command line
+so that it can bodge it correctly to capture output.  It assumes that a
 string C<E<lt>[^E<lt>E<gt>]+\$[^E<lt>E<gt>]E<gt>> 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% right.  Despite all this the problem remains
@@ -819,7 +832,7 @@ Perl has been ported to a variety of platforms that do not fit into any of
 the above categories.  Some, such as AmigaOS, BeOS, QNX, and Plan 9, have
 been well integrated into the standard Perl source code kit.  You may need
 to see the F<ports/> directory on CPAN for information, and possibly
-binaries, for the likes of: aos, atari, lynxos, HP-MPE/iX, riscos, 
+binaries, for the likes of: aos, atari, lynxos, HP-MPE/iX, riscos,
 Tandem Guardian, vos, I<etc.> (yes we know that some of these OSes may fall
 under the Unix category but we are not a standards body.)
 
@@ -1245,7 +1258,7 @@ Not implemented. (S<Mac OS>, Win32, VMS, S<RISC OS>)
 
 =item sysopen FILEHANDLE,FILENAME,MODE,PERMS
 
-The traditional "0", "1", and "2" MODEs are implemented with different 
+The traditional "0", "1", and "2" MODEs are implemented with different
 numeric values on some systems.  The flags exported by C<Fcntl> should work
 everywhere though.  (S<Mac OS>, OS/390)
 
@@ -1314,6 +1327,10 @@ Not useful. (S<RISC OS>)
 
 =over 4
 
+=item 1.32, 05 August 1998
+
+Integrate more minor changes.
+
 =item 1.30, 03 August 1998
 
 Major update for RISC OS, other minor changes.
@@ -1326,31 +1343,33 @@ First public release with perl5.005.
 
 =head1 AUTHORS / CONTRIBUTORS
 
-Chris Nandor E<lt>pudge@pobox.comE<gt>,
-Gurusamy Sarathy E<lt>gsar@umich.eduE<gt>,
-Peter Prymmer E<lt>pvhp@forte.comE<gt>,
+Abigail E<lt>abigail@fnx.comE<gt>,
+Charles Bailey E<lt>bailey@genetics.upenn.eduE<gt>,
+Graham Barr E<lt>gbarr@pobox.comE<gt>,
 Tom Christiansen E<lt>tchrist@perl.comE<gt>,
-Nathan Torkington E<lt>gnat@frii.comE<gt>,
+Nicholas Clark E<lt>Nicholas.Clark@liverpool.ac.ukE<gt>,
+Andy Dougherty E<lt>doughera@lafcol.lafayette.eduE<gt>,
+Dominic Dunlop E<lt>domo@vo.luE<gt>,
+M.J.T. Guy E<lt>mjtg@cus.cam.ac.ukE<gt>,
+Luther Huffman E<lt>lutherh@stratcom.comE<gt>,
+Nick Ing-Simmons E<lt>nick@ni-s.u-net.comE<gt>,
+Andreas J. Koenig E<lt>koenig@kulturbox.deE<gt>,
+Andrew M. Langmead E<lt>aml@world.std.comE<gt>,
 Paul Moore E<lt>Paul.Moore@uk.origin-it.comE<gt>,
+Chris Nandor E<lt>pudge@pobox.comE<gt>,
 Matthias Neercher E<lt>neeri@iis.ee.ethz.chE<gt>,
-Charles Bailey E<lt>bailey@genetics.upenn.eduE<gt>,
-Luther Huffman E<lt>lutherh@stratcom.comE<gt>,
 Gary Ng E<lt>71564.1743@CompuServe.COME<gt>,
-Nick Ing-Simmons E<lt>nick@ni-s.u-net.comE<gt>,
-Paul J. Schinder E<lt>schinder@pobox.comE<gt>,
 Tom Phoenix E<lt>rootbeer@teleport.comE<gt>,
+Peter Prymmer E<lt>pvhp@forte.comE<gt>,
 Hugo van der Sanden E<lt>h.sanden@elsevier.nlE<gt>,
-Dominic Dunlop E<lt>domo@vo.luE<gt>,
+Gurusamy Sarathy E<lt>gsar@umich.eduE<gt>,
+Paul J. Schinder E<lt>schinder@pobox.comE<gt>,
 Dan Sugalski E<lt>sugalskd@ous.eduE<gt>,
-Andreas J. Koenig E<lt>koenig@kulturbox.deE<gt>,
-Andrew M. Langmead E<lt>aml@world.std.comE<gt>,
-Andy Dougherty E<lt>doughera@lafcol.lafayette.eduE<gt>,
-Abigail E<lt>abigail@fnx.comE<gt>,
-Nicholas Clark E<lt>Nicholas.Clark@liverpool.ac.ukE<gt>.
+Nathan Torkington E<lt>gnat@frii.comE<gt>.
 
 This document is maintained by Chris Nandor.
 
 =head1 VERSION
 
-Version 1.30, last modified 03 August 1998.
+Version 1.32, last modified 05 August 1998.