puman4.n

早期freebsd实现

It is extremely inefficient for the Pascal system to send each character
to the user's terminal as the program generates it for output;
even less efficient if the output is the input of another
program such as the line printer daemon
.I lpr
(1).
To gain efficiency, the Pascal system ``buffers'' the output characters
(i.e. it saves them in memory until the buffer is full and then emits
the entire buffer in one system interaction.)
However, to allow interactive prompting to work as in the example given
above, this prompt must be printed before the Pascal system waits for a
response.
For this reason, Pascal normally prints all the output which has
been generated for the file
.I output
whenever
.HP
.RS
.IP 1)
A
.I writeln
occurs, or
.IP 2)
The program reads from the terminal, or
.IP 3)
The procedure
.I message
or
.I flush
is called.
.RE
.LP
Thus, in the code sequence
.ne 5
.LS
\*bfor\fP i := 1 to 5 \*bdo begin\fP
    write(i: 2);
    \fICompute a lot with no output\fP
\*bend;\fP
writeln
.LE
the output integers will not print until the
.I writeln
occurs.
The delay can be somewhat disconcerting, and you should be aware 
that it will occur.
By setting the
.B b
option to 0 before the
.B program
statement by inserting a comment of the form
.LS
(*$b0*)
.LE
we can cause
.I output
to be completely unbuffered, with a corresponding horrendous degradation
in program efficiency.
Option control in comments is discussed in section 5.
.NH 2
Files, reset, and rewrite
.PP
It is possible to use extended forms of the built-in functions
.I reset
and
.I rewrite
to get more general associations of
.UX
file names with Pascal file variables.
When a file other than
.I input
or
.I output
is to be read or written, then the reading or writing must be preceded
by a
.I reset
or
.I rewrite
call.
In general, if the Pascal file variable has never been used before,
there will be no
.UX
filename associated with it.
As we saw in section 2.9,
by mentioning the file in the
.B program
statement,
we could cause a
.UX
file with the same name as the Pascal variable to be associated with it.
If we do not mention a file in the
.B program
statement and use it for the first time with the statement
.LS
reset(f)
.LE
or
.LS
rewrite(f)
.LE
then the Pascal system will generate a temporary name of the form
`tmp.x'
for some character `x',
and associate this
.UX
file name name with the Pascal file.
The first such generated name will be `tmp.1'
and the names continue by incrementing their last character through the
.SM ASCII
set.
The advantage of using such temporary files is that they are automatically
.I remove d
by the Pascal system as soon as they become inaccessible.
They are not removed, however, if a runtime error causes termination
while they are in scope.
.PP
To cause a particular
.UX
pathname to be associated with a Pascal file variable
we can give that name in the
.I reset
or
.I rewrite
call, e.g. we could have associated the Pascal file
.I data
with the file
`primes'
in our example in section 3.1 by doing:
.LS
reset(data, 'primes')
.LE
instead of a simple
.LS
reset(data)
.LE
In this case it is not essential to mention `data'
in the program statement, but it is still a good idea
because is serves as an aid to program documentation.
The second parameter to
.I reset
and
.I rewrite
may be any string value, including a variable.
Thus the names of 
.UX
files to be associated with Pascal file variables can be read
in at run time.
Full details on file name/file variable associations are given in
section A.3.
.NH 2
Argc and argv
.PP
Each
.UX
process receives a variable
length sequence of arguments each of which is a variable length
character string.
The built-in function
.I argc
and the built-in procedure
.I argv
can be used to access and process these arguments.
The value of the function
.I argc
is the number of arguments to the process.
By convention,
the arguments are treated as an array,
and indexed from 0 to
.I argc \-1,
with the zeroth argument being the name of the program being executed.
The rest of the
arguments are those passed to the command on the command line.
Thus, the command
.LS
% \*bobj  /etc/motd  /usr/dict/words hello\fR
.LE
will invoke the program in the file
.I obj
with
.I argc
having a value of 4.
The zeroth element accessed by
.I argv
will be `obj', the first `/etc/motd', etc.
.PP
Pascal does not provide variable size arrays, nor does it allow
character strings of varying length.
For this reason,
.I argv
is a procedure and has the syntax
.LS
argv(i, a)
.LE
where
.I i
is an integer and
.I a
is a string variable.
This procedure call assigns the (possibly truncated or blank padded)
.I i \|'th
argument of the current process to the string variable
.I a .
The file manipulation routines
.I reset
and
.I rewrite
will strip trailing blanks from their optional second arguments
so that this blank padding is not a problem in the usual case
where the arguments are file names.
.PP
We are now ready to give a
Berkeley
Pascal program `kat',
based on that given in section 3.1 above,
which can be used with the same syntax as the
.UX
system program
.I cat
(1).
.LS
% \*bcat kat.p\fR
.so kat3.p
%
.LE
Note that the
.I reset
call to the file
.I input
here, which is necessary for a clear program,
may be disallowed on other systems.
As this program deals mostly with
.I argc
and
.I argv
and
.UX
system dependent considerations,
portability is of little concern.
.PP
If this program is in the file `kat.p', then we can do
.LS
% \*bpi kat.p\fR
% \*bmv obj kat\fR
% \*bkat primes\fR
.so kat2out
% \*bkat\fR
.so katscript
%
.LE
Thus we see that, if it is given arguments, `kat' will,
like
.I cat,
copy each one in turn.
If no arguments are given, it copies from the standard input.
Thus it will work as it did before, with
.LS
% \*bkat < primes\fR
.LE
now equivalent to
.LS
% \*bkat primes\fR
.LE
although the mechanisms are quite different in the two cases.
Note that if `kat' is given a bad file name, for example:
.LS
% \*bkat xxxxqqq\fR
.so xxxxqqqout
%
.LE
it will give a diagnostic and a post-mortem control flow backtrace
for debugging.
If we were going to use `kat', we might want to translate it
differently, e.g.:
.LS
% \*bpi -pb kat.p\fR
% \*bmv obj kat\fR
.LE
Here we have disabled the post-mortem statistics printing, so
as not to get the statistics or the full traceback on error.
The
.B b
option will cause the system to block buffer the input/output so that
the program will run more efficiently on large files.
We could have also specified the
.B t
option to turn off runtime tests if that was felt to be a speed hindrance
to the program.
Thus we can try the last examples again:
.LS
% \*bkat xxxxqqq\fR
.so xxxxqqqout2
% \*bkat primes\fR
.so primes-d
%
.LE
.PP
The interested reader may wish to try writing a program which
accepts command line arguments like
.PI
does, using
.I argc
and
.I argv
to process them.