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},
|
The basic elements of this notation are \emph{process forms},
|
||||||
\emph{extended process forms}, and \emph{redirections}.
|
\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
|
An \emph{extended process form} is a specification of a {\Unix} process to
|
||||||
run, in a particular I/O environment:
|
run, in a particular I/O environment:
|
||||||
\codex{\var{epf} {\synteq} (\var{pf} $ \var{redir}_1$ {\ldots} $ \var{redir}_n $)}
|
\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}.''
|
and \ex{(< /usr/shivers/.login)} means ``read from \ex{/usr/shivers/.login}.''
|
||||||
|
|
||||||
\pagebreak
|
\pagebreak
|
||||||
Here are two more examples of i/o redirection:
|
Here are two more examples of I/O redirection:
|
||||||
%
|
%
|
||||||
\begin{center}
|
\begin{center}
|
||||||
\begin{codebox}
|
\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).
|
(\eg, a string port).
|
||||||
More complex redirections can be accomplished using the \ex{begin}
|
More complex redirections can be accomplished using the \ex{begin}
|
||||||
process form, discussed below, which gives the programmer full control
|
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}
|
\subsection{Port and file descriptor sync}
|
||||||
\begin{sloppypar}
|
\begin{sloppypar}
|
||||||
|
@ -95,7 +95,7 @@ that program would of course not see the {\Scheme} string port as its standard
|
||||||
output.
|
output.
|
||||||
\end{sloppypar}
|
\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}.
|
use the special redirection \ex{stdports}.
|
||||||
This causes 0, 1, 2 to be redirected from the current {\Scheme} standard ports.
|
This causes 0, 1, 2 to be redirected from the current {\Scheme} standard ports.
|
||||||
It is equivalent to the three redirections:
|
It is equivalent to the three redirections:
|
||||||
|
@ -105,9 +105,9 @@ It is equivalent to the three redirections:
|
||||||
(= 2 ,(error-output-port))\end{code}
|
(= 2 ,(error-output-port))\end{code}
|
||||||
%
|
%
|
||||||
The redirections are done in the indicated order. This will cause an error if
|
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).
|
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)}
|
(as opposed to a redirection spec) with the \ex{(stdports->stdio)}
|
||||||
procedure.
|
procedure.
|
||||||
|
|
||||||
|
@ -192,7 +192,7 @@ There are three basic {\Scheme} forms that use extended process forms:
|
||||||
\begin{desc}
|
\begin{desc}
|
||||||
\index{exec-epf} \index{\&} \index{run}
|
\index{exec-epf} \index{\&} \index{run}
|
||||||
The \ex{(exec-epf . \var{epf})} form nukes the current process: it establishes
|
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.
|
computation.
|
||||||
|
|
||||||
The \ex{(\& . \var{epf})} form is similar, except that the process is forked
|
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
|
These special forms are macros that expand into the equivalent
|
||||||
series of system calls.
|
series of system calls.
|
||||||
The definition of the \ex{exec-epf} macro is non-trivial,
|
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:
|
However, the definitions of the \cd{&} and \ex{run} macros are very simple:
|
||||||
\begin{leftinset}
|
\begin{leftinset}
|
||||||
\begin{tabular}{@{}l@{\quad$\equiv$\quad}l@{}}
|
\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?
|
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
|
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:
|
some {\Unix} program \ex{myprog} does the following:
|
||||||
\begin{enumerate}
|
\begin{enumerate}
|
||||||
\item First, outputs a single ``\ex{(}'' to stderr.
|
\item First, outputs a single ``\ex{(}'' to stderr.
|
||||||
|
|
|
@ -132,7 +132,7 @@ This can be overridden if the programmer wishes.
|
||||||
\section{I/O}
|
\section{I/O}
|
||||||
|
|
||||||
\subsection{Standard {\RnRS} I/O procedures}
|
\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.
|
\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
|
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
|
Scsh provides a complete set of routines for manipulating terminal
|
||||||
devices---putting them in ``raw'' mode, changing and querying their
|
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
|
The scsh interface is designed both for generality and portability
|
||||||
across different Unix platforms, so you don't have to rewrite your
|
across different Unix platforms, so you don't have to rewrite your
|
||||||
program each time you move to a new system.
|
program each time you move to a new system.
|
||||||
|
|
Loading…
Reference in New Issue