Unix does the same thing on ttys in canonical mode. C<\015\012>
is commonly referred to as CRLF.
+A common cause of unportable programs is the misuse of chop() to trim
+newlines:
+
+ # XXX UNPORTABLE!
+ while(<FILE>) {
+ chop;
+ @array = split(/:/);
+ #...
+ }
+
+You can get away with this on Unix and MacOS (they have a single
+character end-of-line), but the same program will break under DOSish
+perls because you're only chop()ing half the end-of-line. Instead,
+chomp() should be used to trim newlines. The Dunce::Files module can
+help audit your code for misuses of chop().
+
+When dealing with binary files (or text files in binary mode) be sure
+to explicitly set $/ to the appropriate value for your file format
+before using chomp().
+
Because of the "text" mode translation, DOSish perls have limitations
in using C<seek> and C<tell> on a file accessed in "text" mode.
Stick to C<seek>-ing to locations you got from C<tell> (and no
Conflicting storage orders make utter mess out of the numbers. If a
little-endian host (Intel, VAX) stores 0x12345678 (305419896 in
-decimal), a big-endian host (Motorola, MIPS, Sparc, PA) reads it as
-0x78563412 (2018915346 in decimal). To avoid this problem in network
-(socket) connections use the C<pack> and C<unpack> formats C<n>
-and C<N>, the "network" orders. These are guaranteed to be portable.
+decimal), a big-endian host (Motorola, Sparc, PA) reads it as
+0x78563412 (2018915346 in decimal). Alpha and MIPS can be either:
+Digital/Compaq used/uses them in little-endian mode; SGI/Cray uses
+them in big-endian mode. To avoid this problem in network (socket)
+connections use the C<pack> and C<unpack> formats C<n> and C<N>, the
+"network" orders. These are guaranteed to be portable.
You can explore the endianness of your platform by unpacking a
data structure packed in native format such as:
either of the variables set like so:
$is_big_endian = unpack("h*", pack("s", 1)) =~ /01/;
- $is_litte_endian = unpack("h*", pack("s", 1)) =~ /^1/;
+ $is_little_endian = unpack("h*", pack("s", 1)) =~ /^1/;
Differing widths can cause truncation even between platforms of equal
endianness. The platform of shorter width loses the upper parts of the
notion of a "path" to uniquely identify a file on the system. How
that path is really written, though, differs considerably.
-Atlhough similar, file path specifications differ between Unix,
+Although similar, file path specifications differ between Unix,
Windows, S<Mac OS>, OS/2, VMS, VOS, S<RISC OS>, and probably others.
Unix, for example, is one of the few OSes that has the elegant idea
of a single root directory.
Don't count on a specific environment variable existing in C<%ENV>.
Don't count on C<%ENV> entries being case-sensitive, or even
-case-preserving.
+case-preserving. Don't try to clear %ENV by saying C<%ENV = ();>, or,
+if you really have to, make it conditional on C<$^O ne 'VMS'> since in
+VMS the C<%ENV> table is much more than a per-process key-value string
+table.
Don't count on signals or C<%SIG> for anything.
most platforms (though many of them do not support any type of
forking). The problem with using them arises from what you invoke
them on. External tools are often named differently on different
-platforms, may not be available in the same location, migth accept
+platforms, may not be available in the same location, might accept
different arguments, can behave differently, and often present their
results in a platform-dependent way. Thus, you should seldom depend
on them to produce consistent results. (Then again, if you're calling
Windows NT MSWin32 MSWin32-ppc
Cygwin cygwin
+The various MSWin32 Perl's can distinguish the OS they are running on
+via the value of the fifth element of the list returned from
+Win32::GetOSVersion(). For example:
+
+ if ($^O eq 'MSWin32') {
+ my @os_version_info = Win32::GetOSVersion();
+ print +('3.1','95','NT')[$os_version_info[4]],"\n";
+ }
+
Also see:
=over 4
=item *
The Cygwin environment for Win32; F<README.cygwin> (installed
-as L<perlcygwin>), http://sourceware.cygnus.com/cygwin/
+as L<perlcygwin>), http://www.cygwin.com/
=item *
The U/WIN environment for Win32,
-<http://www.research.att.com/sw/tools/uwin/
+http://www.research.att.com/sw/tools/uwin/
-=item Build instructions for OS/2, L<perlos2>
+=item *
+Build instructions for OS/2, L<perlos2>
=back
=head2 VOS
-Perl on VOS is discussed in F<README.vos> in the perl distribution.
-Perl on VOS can accept either VOS- or Unix-style file
-specifications as in either of the following:
+Perl on VOS is discussed in F<README.vos> in the perl distribution
+(installed as L<perlvos>). Perl on VOS can accept either VOS- or
+Unix-style file specifications as in either of the following:
$ perl -ne "print if /perl_setup/i" >system>notices
$ perl -ne "print if /perl_setup/i" /system/notices
renamed before they can be processed by Perl. Note that VOS limits
file names to 32 or fewer characters.
-The following C functions are unimplemented on VOS, and any attempt by
-Perl to use them will result in a fatal error message and an immediate
-exit from Perl: dup, do_aspawn, do_spawn, fork, waitpid. Once these
-functions become available in the VOS POSIX.1 implementation, you can
-either recompile and rebind Perl, or you can download a newer port from
-ftp.stratus.com.
+See F<README.vos> for restrictions that apply when Perl is built
+with the alpha version of VOS POSIX.1 support.
+
+Perl on VOS is built without any extensions and does not support
+dynamic loading.
The value of C<$^O> on VOS is "VOS". To determine the architecture that
you are running on without resorting to loading all of C<%Config> you
*
-L<perlos390>, F<README.os390>, F<README.posix-bc>, F<README.vmesa>
+L<perlos390>, F<README.os390>, F<perlbs2000>, F<README.vmesa>,
+L<perlebcdic>.
=item *
=item *
AS/400 Perl information at
-ttp://as400.rochester.ibm.com/
+http://as400.rochester.ibm.com/
as well as on CPAN in the F<ports/> directory.
=back
=item *
HP 300 MPE/iX, F<README.mpeix> and Mark Bixby's web page
-http://www.cccd.edu/~markb/perlix.html
+http://www.bixby.org/mark/perlix.html
=item *
precompiled binary and source code form from http://www.novell.com/
as well as from CPAN.
-=item
+=item *
Plan 9, F<README.plan9>
Not implemented. (S<Mac OS>, Win32, VMS, S<RISC OS>, VOS)
+=item sockatmark SOCKET
+
+A relatively recent addition to socket functions, may not
+be implemented even in UNIX platforms.
+
=item socketpair SOCKET1,SOCKET2,DOMAIN,TYPE,PROTOCOL
Not implemented. (S<Mac OS>, Win32, VMS, S<RISC OS>, VOS, VM/ESA)
=item stat
+Platforms that do not have rdev, blksize, or blocks will return these
+as '', so numeric comparison or manipulation of these fields may cause
+'not numeric' warnings.
+
mtime and atime are the same thing, and ctime is creation time instead of
inode change time. (S<Mac OS>)
mtime, atime and ctime all return the last modification time. Device and
inode are not necessarily reliable. (S<RISC OS>)
+dev, rdev, blksize, and blocks are not available. inode is not
+meaningful and will differ between stat calls on the same file. (os2)
+
=item symlink OLDFILE,NEWFILE
Not implemented. (Win32, VMS, S<RISC OS>)
Not implemented. (S<Mac OS>, VOS)
Can only be applied to process handles returned for processes spawned
-using C<system(1, ...)>. (Win32)
+using C<system(1, ...)> or pseudo processes created with C<fork()>. (Win32)
Not useful. (S<RISC OS>)
=head1 SEE ALSO
-L<perlamiga>, L<perlcygwin>, L<perldos>, L<perlhpux>, L<perlos2>,
-L<perlos390>, L<perlwin32>, L<perlvms>, and L<Win32>.
+L<perlaix>, L<perlamiga>, L<perlcygwin>, L<perldos>, L<perlepoc>,
+L<perlebcdic>, L<perlhpux>, L<perlos2>, L<perlos390>, L<perlbs2000>,
+L<perlwin32>, L<perlvms>, L<perlvos>, and L<Win32>.
=head1 AUTHORS / CONTRIBUTORS
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>,
+Jarkko Hietaniemi <jhi@iki.fi>,
Luther Huffman <lutherh@stratcom.com>,
Nick Ing-Simmons <nick@ni-s.u-net.com>,
Andreas J. KE<ouml>nig <koenig@kulturbox.de>,