applied patch, with indentation tweaks

[p5sagit/p5-mst-13.2.git] / pod / perlvar.pod

diff --git a/pod/perlvar.pod b/pod/perlvar.pod
index 6a1ed81..d9edffa 100644 (file)
--- a/pod/perlvar.pod
+++ b/pod/perlvar.pod
@@ -222,6 +222,27 @@ character belongs to the next paragraph, even if it's a newline.
 Remember: the value of $/ is a string, not a regexp.  AWK has to be
 better for something :-)
 
+Setting $/ to a reference to an integer, scalar containing an integer, or
+scalar that's convertable to an integer will attempt to read records
+instead of lines, with the maximum record size being the referenced
+integer. So this:
+
+    $/ = \32768; # or \"32768", or \$var_containing_32768
+    open(FILE, $myfile);
+    $_ = <FILE>;
+
+will read a record of no more than 32768 bytes from FILE. If you're not
+reading from a record-oriented file (or your OS doesn't have
+record-oriented files), then you'll likely get a full chunk of data with
+every read. If a record is larger than the record size you've set, you'll
+get the record back in pieces.
+
+On VMS, record reads are done with the equivalent of C<sysread>, so it's
+best not to mix record and non-record reads on the same file. (This is
+likely not a problem, as any file you'd want to read in record mode is
+proably usable in line mode) Non-VMS systems perform normal I/O, so
+it's safe to mix record and non-record reads of a file.
+
 =item autoflush HANDLE EXPR
 
 =item $OUTPUT_AUTOFLUSH
@@ -413,6 +434,9 @@ C<$? & 255> gives which signal, if any, the process died from, and
 whether there was a core dump.  (Mnemonic: similar to B<sh> and
 B<ksh>.)
 
+Additionally, if the C<h_errno> variable is supported in C, its value
+is returned via $? if any of the C<gethost*()> functions fail.
+
 Note that if you have installed a signal handler for C<SIGCHLD>, the
 value of C<$?> will usually be wrong outside that handler.
 
@@ -451,13 +475,10 @@ the same as C<$!>.
 Under VMS, C<$^E> provides the VMS status value from the last
 system error.  This is more specific information about the last
 system error than that provided by C<$!>.  This is particularly
-important when C<$!> is set to E<EVMSERR>.
+important when C<$!> is set to B<EVMSERR>.
 
-Under OS/2, C<$^E> is set based on the value returned by the OS/2
-call C<_syserrno()> only when a call into the OS/2 API generates
-an error.  In this case, C<$!> is set to a special value to
-indicate that C<$^E> should be checked.  Otherwise, C<$^E> is
-just the same as C<$!>.
+Under OS/2, C<$^E> is set to the error code of the last call to
+OS/2 API either via CRT, or directly from perl.
 
 Under Win32, C<$^E> always returns the last error information
 reported by the Win32 call C<GetLastError()> which describes
@@ -692,7 +713,7 @@ run-time only. This is a new mechanism and the details may change.
 
 Current state of the interpreter.  Undefined if parsing of the current
 module/eval is not finished (may happen in $SIG{__DIE__} and
-$SIG{__WARN__} handlers).  True if inside an eval, othewise false.
+$SIG{__WARN__} handlers).  True if inside an eval, otherwise false.
 
 =item $BASETIME
 
@@ -824,7 +845,7 @@ The C<__DIE__> handler is explicitly disabled during the call, so that you
 can die from a C<__DIE__> handler.  Similarly for C<__WARN__>.
 
 Note that the C<$SIG{__DIE__}> hook is called even inside eval()ed
-blocks/strings.  See L<perlfunc/die>, L<perlvar/$^S> for how to
+blocks/strings.  See L<perlfunc/die> and L<perlvar/$^S> for how to
 circumvent this.
 
 Note that C<__DIE__>/C<__WARN__> handlers are very special in one