(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
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
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
C<closedir> instead.
Don't count on per-program environment variables, or per-program current
-directores.
+directories.
=head2 Interprocess Communication (IPC)
=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
$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:
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
Native filenames are of the form
Filesystem#Special_Field::DiscName.$.Directory.Directory.File
-
+
where
Special_Field is not usually present, but may contain . and $ .
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
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.)
=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)
=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.
=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.