puman4.n

早期freebsd实现

.\" Copyright (c) 1980, 1993
.\"	The Regents of the University of California.  All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\"    notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\"    notice, this list of conditions and the following disclaimer in the
.\"    documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\"    must display the following acknowledgement:
.\"	This product includes software developed by the University of
.\"	California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\"    may be used to endorse or promote products derived from this software
.\"    without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\"
.\"	@(#)puman4.n	8.1 (Berkeley) 6/8/93
.\"
.if !\n(xx \{\
.so tmac.p \}
.nr H1 3
.if n 'ND
.NH
Input/output
.PP
This section describes features of the Pascal input/output environment,
with special consideration of the features peculiar to an
interactive implementation.
.NH 2
Introduction
.PP
Our first sample programs, in section 2, used the file
.I output .
We gave examples there of redirecting the output to a file and to the line
printer using the shell.
Similarly, we can read the input from a file or another program.
Consider the following Pascal program which is similar to the program
.I cat 
(1).
.LS
% \*bpix -l kat.p <primes\fR
.so katout
%
.LE
Here we have used the shell's syntax to redirect the program input from
a file in
.I primes
in which we had placed the output of our prime number program of section 2.6.
It is also possible to
`pipe' input to this program much as we piped input
to the line printer daemon
.I lpr
(1)
before.
Thus, the same output as above would be produced by
.LS
% \*bcat primes | pix -l kat.p\fR
.LE
.PP
All of these examples use the shell to control the input and output
from files.
One very simple way to associate Pascal files with named
.UX
files is to place the file name in the
.B program
statement.
For example, suppose we have previously created the file
.I data.
We then use it as input to another version of a listing program.
.LS
% \*bcat data\fR
.so data
% \*bpix -l copydata.p\fR
.so copydataout
%
.LE
By mentioning the file
.I data
in the
.B program
statement, we have indicated that we wish it
to correspond to the
.UX
file
.I data .
Then, when we
`reset(data)',
the Pascal system opens our file `data' for reading.
More sophisticated, but less portable, examples of using
.UX
files will be given in sections 4.5 and 4.6.
There is a portability problem even with this simple example.
Some Pascal systems attach meaning to the ordering of the file in the
.B program
statement file list.
.UP
does not do so.
.NH 2
Eof and eoln
.PP
An extremely common problem encountered by new users of Pascal, especially
in the interactive environment offered by
.UX ,
relates to the definitions of
.I eof
and
.I eoln .
These functions are supposed to be defined at the beginning of execution of
a Pascal program, indicating whether the input device is at the end of a
line or the end of a file.
Setting
.I eof
or
.I eoln
actually corresponds to an implicit read in which the input is
inspected, but no input is ``used up''.
In fact, there is no way the system can know whether the input is
at the end-of-file or the end-of-line unless it attempts to read a line from it.
If the input is from a previously created file,
then this reading can take place without run-time action by the user.
However, if the input is from a terminal, then the input
is what the user types.\*(dg
If the system were to do an initial read
automatically at the beginning of program execution,
and if the input were a terminal,
the user would have to type some input before execution could begin.
.FS
\*(dgIt is not possible to determine whether the input is
a terminal, as the input may appear to be a file but actually be a
.I pipe,
the output of a program which is reading from the terminal.
.FE
This would make it impossible for the program to begin by prompting
for input or printing a herald.
.PP
.UP
has been designed so that an initial read is not necessary.
At any given time, the Pascal system may or may not know whether the
end-of-file or end-of-line conditions are true.
Thus, internally, these functions can have three values \-
true, false, and ``I don't know yet; if you ask me I'll have to
find out''.
All files remain in this last, indeterminate state until the Pascal
program requires a value for
.I eof
or
.I eoln
either explicitly or implicitly, e.g. in a call to
.I read .
The important point to note here is that if you force the Pascal
system to determine whether the input is at the end-of-file or the end-of-line,
it will be necessary for it to attempt to read from the input.
.PP
Thus consider the following example code
.LS
\*bwhile not\fP eof \*bdo\fP \*bbegin\fP
    write('number, please? ');
    read(i);
    writeln('that was a ', i: 2)
\*bend\fP
.LE
At first glance, this may be appear to be a correct program
for requesting, reading and echoing numbers.
Notice, however, that the
.B while
loop asks whether
.I eof
is true
.I before
the request is printed.
This will force the Pascal system to decide whether the input is at the
end-of-file.
The Pascal system will give no messages;
it will simply wait for the user to type a line.
By producing the desired prompting before testing
.I eof,
the following code avoids this problem:
.LS
write('number, please ?');
\*bwhile not\fP eof \*bdo\fP \*bbegin\fP
    read(i);
    writeln('that was a ', i:2);
    write('number, please ?')
\*bend\fP
.LE
The user must still type a line before the
.B while
test is completed, but the prompt will ask for it.
This example, however, is still not correct.
To understand why, it is first necessary to know, as we will discuss below,
that there is a blank character at the end of each line in a Pascal text
file.
The
.I read
procedure, when reading integers or real numbers,
is defined so that,
if there are only blanks left in the file,
it will return a zero value and set the end-of-file condition.
If, however, there is a number remaining in the file, the end-of-file
condition will not be set even if it is the last number, as
.I read
never reads the blanks after the number, and there is always at least
one blank.
Thus the modified code will still put out a spurious
.LS
that was a 0
.LE
at the end of a session with it when the end-of-file is reached.
The simplest way to correct the problem in this example is to use the procedure
.I readln
instead of
.I read
here.
In general, unless we test the end-of-file condition both before and
after calls to
.I read
or
.I readln ,
there will be inputs for which our program will attempt
to read past end-of-file.
.NH 2
More about eoln
.PP
To have a good understanding of when
.I eoln
will be true it is necessary to know that in any file
there is a special character indicating end-of-line,
and that, in effect, the Pascal system always reads one character ahead of the 
Pascal
.I read
commands.\*(dg
.FS
\*(dgIn Pascal terms,
`read(ch)'
corresponds to
`ch := input^; get(input)'
.FE
For instance,
in response to `read(ch)',
the system sets
.I ch
to the current input character and gets the next input character.
If the current input character is the last character of the line,
then the next input character from the file is the new-line character,
the normal
.UX
line separator.
When the read routine gets the new-line character,
it replaces that character by a blank
(causing every line to end with a blank)
and sets
.I eoln
to true.
.I Eoln
will be true as soon as we read the last character of the line and
.B before
we read the blank character corresponding to the end of line.
Thus it is almost always a mistake to write a program which deals with
input in the following way:
.LS
read(ch);
\*bif\fP eoln \*bthen\fP
    \fIDone with line\fP
\*belse\fP
    \fINormal processing\fP
.LE
as this will almost surely have the effect of ignoring the last character
in the line.
The `read(ch)' belongs as part of the normal processing.
.PP
Given this framework, it is not hard to explain the function of a
.I readln
call, which is defined as:
.LS
\*bwhile not\fP eoln \*bdo\fP
    get(input);
get(input);
.LE
This advances the file until the blank corresponding to the end-of-line
is the current input symbol and then discards this blank.
The next character available from
.I read
will therefore be the first character of the next line,
if one exists.
.NH 2
Output buffering
.PP
A final point about Pascal input-output must be noted here.
This concerns the buffering of the file
.I output .