Consistently replace "i/o" -> "I/O".

doc/scsh-manual/syscalls.tex

@@ -134,7 +134,7 @@ This can be overridden if the programmer wishes.
 \subsection{Standard {\RnRS} I/O procedures}
 In scsh, most standard {\RnRS} i/o operations (such as \ex{display} or
 \ex{read-char}) work on both integer file descriptors and {\Scheme} ports.
-When doing i/o with a file descriptor, the i/o operation is done
+When doing I/O with a file descriptor, the I/O operation is done
 directly on the file, bypassing any buffered data that may have
 accumulated in an associated port.
 Note that character-at-a-time operations such as \ex{read-char}
@@ -297,10 +297,10 @@ You may safely skim or completely skip this section on a first reading.
 Dealing with {\Unix} file descriptors in a {\Scheme} environment is difficult. 
 In {\Unix}, open files are part of the process environment, and are referenced
 by small integers called \emph{file descriptors}. Open file descriptors are
-the fundamental way i/o redirections are passed to subprocesses, since
+the fundamental way I/O redirections are passed to subprocesses, since
 file descriptors are preserved across fork's and exec's.
 
-{\Scheme}, on the other hand, uses ports for specifying i/o sources. Ports are
+{\Scheme}, on the other hand, uses ports for specifying I/O sources. Ports are
 garbage-collected {\Scheme} objects, not integers. Ports can be garbage
 collected; when a port is collected, it is also closed. Because file
 descriptors are just integers, it's impossible to garbage collect them---you
@@ -593,7 +593,7 @@ this is dependent on the OS implementation.
   The returned port is an input port if the \var{flags} permit it, 
   otherwise an output port. \RnRS/\scm/scsh do not have input/output ports,
   so it's one or the other. This should be fixed. (You can hack simultaneous
-  i/o on a file by opening it r/w, taking the result input port, 
+  I/O on a file by opening it r/w, taking the result input port, 
   and duping it to an output port with \ex{dup->outport}.)
 \end{defundesc}
 
@@ -746,7 +746,7 @@ Returns two ports, the read and write end-points of a {\Unix} pipe.
   (barring eof).
 
   There is one case in which the forward-progress guarantee is cancelled:
-  when the programmer explicitly sets the port to non-blocking i/o.
+  when the programmer explicitly sets the port to non-blocking I/O.
   In this case, if no data is immediately available, 
   the procedure will not block, but will immediately return a zero-byte read.
 
@@ -764,7 +764,7 @@ Returns two ports, the read and write end-points of a {\Unix} pipe.
   A request to read zero bytes returns immediatedly, with no eof check.
 
   In sum, there are only three ways you can get a zero-byte read:
-  (1) you request one, (2) you turn on non-blocking i/o, or (3) you
+  (1) you request one, (2) you turn on non-blocking I/O, or (3) you
   try to read at eof.
 
   These are the routines to use for non-blocking input.
@@ -868,7 +868,7 @@ Returns two ports, the read and write end-points of a {\Unix} pipe.
     (due to interrupts or partial writes),
     it will perform multiple write operations until all the data is written
     or an error has occurred.
-    A non-blocking i/o error is considered an error.
+    A non-blocking I/O error is considered an error.
     (Error exception packets for this syscall include the amount of
      data partially transferred before the error occurred.)
 
@@ -893,9 +893,9 @@ Returns two ports, the read and write end-points of a {\Unix} pipe.
     asked for.
     Partial writes can occur when (1) we write off the physical end of
     the media, (2) the write is interrrupted, or (3) the file descriptor
-    is set for non-blocking i/o.
+    is set for non-blocking I/O.
 
-    If the file descriptor is not set up for non-blocking i/o, then
+    If the file descriptor is not set up for non-blocking I/O, then
     a successful return from these procedures makes a forward progress
     guarantee---that is, a partial write took place of at least one byte:
     \begin{itemize}
@@ -908,14 +908,14 @@ Returns two ports, the read and write end-points of a {\Unix} pipe.
     \end{itemize}
 
     If we request a zero-byte write, then the call immediately returns 0.
-    If the file descriptor is set for non-blocking i/o, then the call
+    If the file descriptor is set for non-blocking I/O, then the call
     may return 0 if it was unable to immediately write anything
     (\eg, full pipe).
     Barring these two cases, a write either returns $\var{nwritten} > 0$, 
     or raises an error exception.
 
-    Non-blocking i/o is only available on file descriptors and unbuffered
-    ports. Doing non-blocking i/o to a buffered port is not well-defined,
+    Non-blocking I/O is only available on file descriptors and unbuffered
+    ports. Doing non-blocking I/O to a buffered port is not well-defined,
     and is an error (the problem is the subsequent flush operation).
 \end{defundescx}
 
@@ -1654,7 +1654,7 @@ delimiter.
     that collisions are less likely to occur. This speeds things up, but does
     not affect correctness.
 
-    Security note: doing i/o to files created this way in \ex{/var/tmp/} is
+    Security note: doing I/O to files created this way in \ex{/var/tmp/} is
     not necessarily secure. General users have write access to \ex{/var/tmp/},
     so even if an attacker cannot access the new temp file, he can delete it
     and replace it with one of his own. A subsequent open of this filename
@@ -1766,7 +1766,7 @@ delimiter.
        simply see and report an end of file. This is bad.
 
        In order to ensure that an end-of-file returned to the reader is
-       legitimate, the reader and writer must serialise their i/o. The
+       legitimate, the reader and writer must serialise their I/O. The
        simplest way to do this is for the reader to delay doing input
        until the writer has completely finished doing output, or exited.
     \end{itemize}