VMS, Windows, and OS/2 can work similarly to Unix with C</> as path
separator, or in their own idiosyncratic ways (such as having several
-root directories and various "unrooted" device files such NIL: and
+root directories and various "unrooted" device files such NIL: and
LPT:).
S<Mac OS> uses C<:> as a path separator instead of C</>.
splits a pathname into pieces (base filename, full path to directory,
and file suffix).
-Even when on a single platform (if you can call UNIX a single
-platform), remember not to count on the existence or the contents of
-system-specific files, like F</etc/passwd>, F</etc/sendmail.conf>, or
-F</etc/resolv.conf>. For example the F</etc/passwd> may exist but it
-may not contain the encrypted passwords because the system is using
-some form of enhanced security-- or it may not contain all the
-accounts because the system is using NIS. If code does need to rely
-on such a file, include a description of the file and its format in
-the code's documentation, and make it easy for the user to override
-the default location of the file.
+Even when on a single platform (if you can call UNIX a single platform),
+remember not to count on the existence or the contents of
+system-specific files or directories, like F</etc/passwd>,
+F</etc/sendmail.conf>, F</etc/resolv.conf>, or even F</tmp/>. For
+example, F</etc/passwd> may exist but it may not contain the encrypted
+passwords because the system is using some form of enhanced security --
+or it may not contain all the accounts because the system is using NIS.
+If code does need to rely on such a file, include a description of the
+file and its format in the code's documentation, and make it easy for
+the user to override the default location of the file.
+
+Don't assume a text file will end with a newline.
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
+F<test.pl> and F<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.
make it so the resulting files have a unique (case-insensitively)
first 8 characters.
-Don't assume C<E<lt>> 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<E<gt>> won't be the first character of a filename. Always
+use C<E<lt>> explicitly to open a file for reading.
open(FILE, "<$existing_file") or die $!;
+Actually, though, if filenames might use strange characters, it is
+safest to open it with C<sysopen> instead of C<open>, which is magic.
+
=head2 System Interaction
Don't count on per-program environment variables, or per-program current
directories.
+Don't count on specific values of C<$!>.
+
=head2 Interprocess Communication (IPC)
The UNIX System V IPC (C<msg*(), sem*(), shm*()>) is not available
even in all UNIX platforms.
+
=head2 External Subroutines (XS)
XS code, in general, can be made to work with any platform; but dependent
Assume very little about character sets. Do not assume anything about
the numerical values (C<ord()>, C<chr()>) of characters. Do not
assume that the alphabetic characters are encoded contiguously (in
-numerical sense). Do no assume anything about the ordering of the
+numerical sense). Do not assume anything about the ordering of the
characters. The lowercase letters may come before or after the
uppercase letters, the lowercase and uppercase may be interlaced so
that both 'a' and 'A' come before the 'b', the accented and other
=head2 Internationalisation
-If you may assume POSIX (a rather large assumption, that: in practise
-that means UNIX) you may read more about the POSIX locale system from
+If you may assume POSIX (a rather large assumption, that in practice
+means UNIX), you may read more about the POSIX locale system from
L<perllocale>. The locale system at least attempts to make things a
-little bit more portable or at least more convenient and
+little bit more portable, or at least more convenient and
native-friendly for non-English users. The system affects character
sets and encoding, and date and time formatting, among other things.
FreeBSD freebsd freebsd-i386
Linux linux i386-linux
HP-UX hpux PA-RISC1.1
- IRIX irix irix
+ IRIX irix irix
OSF1 dec_osf alpha-dec_osf
SunOS solaris sun4-solaris
SunOS solaris i86pc-solaris
which is reserved as a path separator.
Instead of C<flock>, see C<FSpSetFLock> and C<FSpRstFLock> in the
-C<Mac::Files> module.
+C<Mac::Files> module, or C<chmod(0444, ...)> and C<chmod(0666, ...)>.
In the MacPerl application, you can't run a program from the command line;
programs that expect C<@ARGV> to be populated can be edited with something
$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.
+S<Mac OS X>, to be based on NeXT's OpenStep OS, will (in theory) be able
+to run MacPerl natively, but Unix perl will also run natively under the
+built-in Unix environment.
Also see:
The value of C<$^O> on OS/390 is "os390".
The value of C<$^O> on VM/ESA is "vmesa".
+
Some simple tricks for determining if you are running on an EBCDIC
platform could include any of the following (perhaps all):
expand system variables in filenames if enclosed in angle brackets, so
C<E<lt>System$DirE<gt>.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<E<lt>E<gt>>> and should
be protected when C<open> is used for input.
Because C<.> was in use as a directory separator and filenames could not
Not implemented. (S<Mac OS>)
Implemented via Spawn. (VM/ESA)
+
=item fcntl FILEHANDLE,FUNCTION,SCALAR
Not implemented. (Win32, VMS)
=over 4
-=item 1.35, 9 September 1998
+=item v1.37, 19 December 1998
+
+More minor changes. Merge two separate version 1.35 documents.
+
+=item v1.36, 9 September 1998
+
+Updated for Stratus VOS. Also known as version 1.35.
+
+=item v1.35, 13 August 1998
-Updated for Stratus VOS.
+Integrate more minor changes, plus addition of new sections under
+L<"ISSUES">: L<"Numbers endianness and Width">,
+L<"Character sets and character encoding">,
+L<"Internationalisation">.
-=item 1.33, 06 August 1998
+=item v1.33, 06 August 1998
Integrate more minor changes.
-=item 1.32, 05 August 1998
+=item v1.32, 05 August 1998
Integrate more minor changes.
-=item 1.30, 03 August 1998
+=item v1.30, 03 August 1998
Major update for RISC OS, other minor changes.
-=item 1.23, 10 July 1998
+=item v1.23, 10 July 1998
First public release with perl5.005.
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>,
Paul Moore E<lt>Paul.Moore@uk.origin-it.comE<gt>,
Chris Nandor E<lt>pudge@pobox.comE<gt>,
Dan Sugalski E<lt>sugalskd@ous.eduE<gt>,
Nathan Torkington E<lt>gnat@frii.comE<gt>.
-This document is maintained by Chris Nandor.
+This document is maintained by Chris Nandor
+E<lt>pudge@pobox.comE<gt>.
=head1 VERSION
-Version 1.35, last modified 09 September 1998.
+Version 1.37, last modified 19 December 1998