From dd9f0070190bd7c99e6ea3d164a54285586358ad Mon Sep 17 00:00:00 2001 From: Chris Nandor Date: Wed, 5 Aug 1998 11:38:48 -0400 Subject: [PATCH] perlport 1.32 Message-Id: p4raw-id: //depot/maint-5.005/perl@1744 --- pod/perlport.pod | 75 +++++++++++++++++++++++++++++++++++--------------------- 1 file changed, 47 insertions(+), 28 deletions(-) diff --git a/pod/perlport.pod b/pod/perlport.pod index 63fee2f..3c1fba6 100644 --- 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, OS/2, VMS, S and probably others. Unix, +Windows, S, OS/2, VMS, S and probably others. Unix, for example, is one of the few OSes that has the idea of a root directory. S 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, as some platforms can use characters such as C> which will perl C will interpret and eat. +Do not have two files of the same name with different case, like +F and , 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, 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, C, and C instead. Don't count on per-program environment variables, or per-program current -directores. +directories. =head2 Interprocess Communication (IPC) @@ -462,7 +472,7 @@ C =back -=head2 MacPerl +=head2 S 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, 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 with a file named F will return F (though that file could be opened with C. RMS had an eight level limit on directory depths from any rooted logical -(allowing 16 levels overall) prior to VMS 7.2. Hence -C is a valid directory specification but -C is not. F 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 is a valid directory specification but +C is not. F authors might +have to take this into account, but at least they can refer to the former as C. The C 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 CFoo$DirE.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[^EE]+\$[^EE]E> is a reference to an environment variable, whereas anything else involving C> or C> 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 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 (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, Win32, VMS, S) =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 should work everywhere though. (S, OS/390) @@ -1314,6 +1327,10 @@ Not useful. (S) =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 Epudge@pobox.comE, -Gurusamy Sarathy Egsar@umich.eduE, -Peter Prymmer Epvhp@forte.comE, +Abigail Eabigail@fnx.comE, +Charles Bailey Ebailey@genetics.upenn.eduE, +Graham Barr Egbarr@pobox.comE, Tom Christiansen Etchrist@perl.comE, -Nathan Torkington Egnat@frii.comE, +Nicholas Clark ENicholas.Clark@liverpool.ac.ukE, +Andy Dougherty Edoughera@lafcol.lafayette.eduE, +Dominic Dunlop Edomo@vo.luE, +M.J.T. Guy Emjtg@cus.cam.ac.ukE, +Luther Huffman Elutherh@stratcom.comE, +Nick Ing-Simmons Enick@ni-s.u-net.comE, +Andreas J. Koenig Ekoenig@kulturbox.deE, +Andrew M. Langmead Eaml@world.std.comE, Paul Moore EPaul.Moore@uk.origin-it.comE, +Chris Nandor Epudge@pobox.comE, Matthias Neercher Eneeri@iis.ee.ethz.chE, -Charles Bailey Ebailey@genetics.upenn.eduE, -Luther Huffman Elutherh@stratcom.comE, Gary Ng E71564.1743@CompuServe.COME, -Nick Ing-Simmons Enick@ni-s.u-net.comE, -Paul J. Schinder Eschinder@pobox.comE, Tom Phoenix Erootbeer@teleport.comE, +Peter Prymmer Epvhp@forte.comE, Hugo van der Sanden Eh.sanden@elsevier.nlE, -Dominic Dunlop Edomo@vo.luE, +Gurusamy Sarathy Egsar@umich.eduE, +Paul J. Schinder Eschinder@pobox.comE, Dan Sugalski Esugalskd@ous.eduE, -Andreas J. Koenig Ekoenig@kulturbox.deE, -Andrew M. Langmead Eaml@world.std.comE, -Andy Dougherty Edoughera@lafcol.lafayette.eduE, -Abigail Eabigail@fnx.comE, -Nicholas Clark ENicholas.Clark@liverpool.ac.ukE. +Nathan Torkington Egnat@frii.comE. 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. -- 2.7.4