On Tue, 1 May 2001, Peter Prymmer wrote:
> situation. Please comment on it: does the change look ok? Would
> you suggest a re-wording? Are there any other misleading or incorrect
> portions of the perl documentation? Thanks very much for your comments.
Here is a revision with text for sending to pumpkinigs/p5p, et al.
Comments, suggestions, derisions, objections, etc. would still
be welcomed at this time:
--------------------------------------------
Greetings,
The enclosed doc patch corrects some misinformation about the nature of I/O on
VMS in perlfunc.pod. I have tried to find where this mistake was introduced,
but I have so far been unsuccessful in using the xray.mpe.mpg.de archive.
I have also tried to clarify default behavior in perlport.pod to hopefully
avert this problem in the future.
For illustration allow me to show how perl on VMS differs from DOSish I/O.
C<dump/byte/decimal> is roughly equivalent to `od -t d` on unix with a different
output format. C<directory/full> is a bit like `ls -s` on steroids,
C<search> is a bit like grep with reversed arguments (and is used solely to cut
down on the verbosity of the output from the other programs here):
$ perl -e "print ""ABC\nDEF\cZGHI\nJKL\n"";" > test.out
$ pipe dump/byte/decimal test.out | search sys$input "ABC","bytes"
Virtual block number 1 (00000001), 512 (0200) bytes
10 76 75 74 10 73 72 71 26 70 69 68 10 67 66 65 ABC.DEF.GHI.JKL.
0
$ pipe directory/full test.out | search sys$input "File attributes:","Record format:"
File attributes: Allocation: 9, Extend: 0, Global buffer count: 0, No version limit
Record format: Stream_LF, maximum 0 bytes, longest 32767 bytes
Here it is:
diff -ru perl_9945_orig/pod/perlfunc.pod perl_9945/pod/perlfunc.pod
--- perl_9945_orig/pod/perlfunc.pod Wed May 2 12:08:56 2001
+++ perl_9945/pod/perlfunc.pod Wed May 2 12:09:28 2001
@@ -474,17 +474,17 @@
platforms the external representation of C<\n> is made up of more than
one character.
-Mac OS and all variants of Unix use a single character to end each line
-in the external representation of text (even though that single
-character is not necessarily the same across these platforms).
-Consequently binmode() has no effect on these operating systems. In
-other systems like VMS, MS-DOS and the various flavors of MS-Windows
-your program sees a C<\n> as a simple C<\cJ>, but what's stored in text
-files are the two characters C<\cM\cJ>. That means that, if you don't
-use binmode() on these systems, C<\cM\cJ> sequences on disk will be
-converted to C<\n> on input, and any C<\n> in your program will be
-converted back to C<\cM\cJ> on output. This is what you want for text
-files, but it can be disastrous for binary files.
+Mac OS, all variants of Unix, and Stream_LF files on VMS use a single
+character to end each line in the external representation of text (even
+though that single character is CARRIAGE RETURN on Mac OS and LINE FEED
+on Unix and most VMS files). Consequently binmode() has no effect on
+these operating systems. In other systems like OS/2, DOS and the various
+flavors of MS-Windows your program sees a C<\n> as a simple C<\cJ>, but
+what's stored in text files are the two characters C<\cM\cJ>. That means
+that, if you don't use binmode() on these systems, C<\cM\cJ> sequences on
+disk will be converted to C<\n> on input, and any C<\n> in your program
+will be converted back to C<\cM\cJ> on output. This is what you want for
+text files, but it can be disastrous for binary files.
Another consequence of using binmode() (on some systems) is that
special end-of-file markers will be seen as part of the data stream.
diff -ru perl_9945_orig/pod/perlport.pod perl_9945/pod/perlport.pod
--- perl_9945_orig/pod/perlport.pod Wed May 2 12:09:05 2001
+++ perl_9945/pod/perlport.pod Wed May 2 12:09:17 2001
@@ -874,10 +874,11 @@
non-VMS platforms and can be helpful for conversions to and from RMS
native formats.
-What C<\n> represents depends on the type of file opened. It could
-be C<\015>, C<\012>, C<\015\012>, or nothing. The VMS::Stdio module
-provides access to the special fopen() requirements of files with unusual
-attributes on VMS.
+What C<\n> represents depends on the type of file opened. It usually
+represents C<\012> but it could also be C<\015>, C<\012>, C<\015\012>,
+C<\000>, C<\040>, or nothing depending on the file organiztion and
+record format. The VMS::Stdio module provides access to the
+special fopen() requirements of files with unusual attributes on VMS.
TCP/IP stacks are optional on VMS, so socket routines might not be
implemented. UDP sockets may not be supported.
End of Patch.
Peter Prymmer
