i/o -> I/O
This commit is contained in:
parent
0b2bc63faf
commit
c74b97c7b9
|
@ -8,7 +8,7 @@ standard {\Scheme} code.
|
|||
The basic elements of this notation are \emph{process forms},
|
||||
\emph{extended process forms}, and \emph{redirections}.
|
||||
|
||||
\section{Extended process forms and i/o redirections}
|
||||
\section{Extended process forms and I/O redirections}
|
||||
An \emph{extended process form} is a specification of a {\Unix} process to
|
||||
run, in a particular I/O environment:
|
||||
\codex{\var{epf} {\synteq} (\var{pf} $ \var{redir}_1$ {\ldots} $ \var{redir}_n $)}
|
||||
|
@ -35,7 +35,7 @@ So \ex{(> ,x)} means
|
|||
and \ex{(< /usr/shivers/.login)} means ``read from \ex{/usr/shivers/.login}.''
|
||||
|
||||
\pagebreak
|
||||
Here are two more examples of i/o redirection:
|
||||
Here are two more examples of I/O redirection:
|
||||
%
|
||||
\begin{center}
|
||||
\begin{codebox}
|
||||
|
@ -73,7 +73,7 @@ In this case, it is an error if the port is not a file port
|
|||
(\eg, a string port).
|
||||
More complex redirections can be accomplished using the \ex{begin}
|
||||
process form, discussed below, which gives the programmer full control
|
||||
of i/o redirection from {\Scheme}.
|
||||
of I/O redirection from {\Scheme}.
|
||||
|
||||
\subsection{Port and file descriptor sync}
|
||||
\begin{sloppypar}
|
||||
|
@ -95,7 +95,7 @@ that program would of course not see the {\Scheme} string port as its standard
|
|||
output.
|
||||
\end{sloppypar}
|
||||
|
||||
To keep stdio synced with the values of {\Scheme}'s current i/o ports,
|
||||
To keep stdio synced with the values of {\Scheme}'s current I/O ports,
|
||||
use the special redirection \ex{stdports}.
|
||||
This causes 0, 1, 2 to be redirected from the current {\Scheme} standard ports.
|
||||
It is equivalent to the three redirections:
|
||||
|
@ -105,9 +105,9 @@ It is equivalent to the three redirections:
|
|||
(= 2 ,(error-output-port))\end{code}
|
||||
%
|
||||
The redirections are done in the indicated order. This will cause an error if
|
||||
one of the current i/o ports isn't a {\Unix} port (\eg, if one is a string
|
||||
one of the current I/O ports isn't a {\Unix} port (\eg, if one is a string
|
||||
port).
|
||||
This {\Scheme}/{\Unix} i/o synchronisation can also be had in {\Scheme} code
|
||||
This {\Scheme}/{\Unix} I/O synchronisation can also be had in {\Scheme} code
|
||||
(as opposed to a redirection spec) with the \ex{(stdports->stdio)}
|
||||
procedure.
|
||||
|
||||
|
@ -192,7 +192,7 @@ There are three basic {\Scheme} forms that use extended process forms:
|
|||
\begin{desc}
|
||||
\index{exec-epf} \index{\&} \index{run}
|
||||
The \ex{(exec-epf . \var{epf})} form nukes the current process: it establishes
|
||||
the i/o redirections and then overlays the current process with the requested
|
||||
the I/O redirections and then overlays the current process with the requested
|
||||
computation.
|
||||
|
||||
The \ex{(\& . \var{epf})} form is similar, except that the process is forked
|
||||
|
@ -205,7 +205,7 @@ and returns its exit status.
|
|||
These special forms are macros that expand into the equivalent
|
||||
series of system calls.
|
||||
The definition of the \ex{exec-epf} macro is non-trivial,
|
||||
as it produces the code to handle i/o redirections and set up pipelines.
|
||||
as it produces the code to handle I/O redirections and set up pipelines.
|
||||
However, the definitions of the \cd{&} and \ex{run} macros are very simple:
|
||||
\begin{leftinset}
|
||||
\begin{tabular}{@{}l@{\quad$\equiv$\quad}l@{}}
|
||||
|
@ -426,7 +426,7 @@ might produce the list
|
|||
|
||||
What is the deadlock hazard that causes \ex{run/collecting} to use temp files?
|
||||
Processes with multiple output streams can lock up if they use pipes
|
||||
to communicate with {\Scheme} i/o readers. For example, suppose
|
||||
to communicate with {\Scheme} I/O readers. For example, suppose
|
||||
some {\Unix} program \ex{myprog} does the following:
|
||||
\begin{enumerate}
|
||||
\item First, outputs a single ``\ex{(}'' to stderr.
|
||||
|
|
|
@ -132,7 +132,7 @@ This can be overridden if the programmer wishes.
|
|||
\section{I/O}
|
||||
|
||||
\subsection{Standard {\RnRS} I/O procedures}
|
||||
In scsh, most standard {\RnRS} i/o operations (such as \ex{display} or
|
||||
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
|
||||
directly on the file, bypassing any buffered data that may have
|
||||
|
|
|
@ -9,7 +9,7 @@
|
|||
|
||||
Scsh provides a complete set of routines for manipulating terminal
|
||||
devices---putting them in ``raw'' mode, changing and querying their
|
||||
special characters, modifying their i/o speeds, and so forth.
|
||||
special characters, modifying their I/O speeds, and so forth.
|
||||
The scsh interface is designed both for generality and portability
|
||||
across different Unix platforms, so you don't have to rewrite your
|
||||
program each time you move to a new system.
|
||||
|
|
Loading…
Reference in New Issue