home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
CP/M
/
CPM_CDROM.iso
/
cpm
/
aztec-c
/
azpipe11.ark
/
AZPIPE11.DOC
< prev
next >
Wrap
Text File
|
1989-11-12
|
4KB
|
85 lines
AZPIPE11.DOC
12 Nov. 89
In the March, 1985, issue of Doctor Dobb's Journal, Allen Holub
described a tidy alteration to the Croot() function of Aztec C
for CP/M, version 1.05, which implemented pipes -- one of the
UNIX-like features which we all, in our insatiable hunger for
power, would like most to have. Unfortunately, this was also
about the time when Manx came out with their version 1.06, which
had an array of new features, bug fixes, etc., and the disturbing
character that the source of the library was no longer part of
the package, as it had been, but cost an extra $150. (It is
already stiff at the $200 base price.) Croot() of v. 1.06 is
then inaccessible to Holub's modifications without significant
extra expense.
So what azpipe.c does is implement piping apart from the Croot()
function. Then it should be useful with any version which uses
the same structures (fcbtab and channel) for i/o and has the
library routines freopen() and execv().
Pipes are set up by linking AZPIPE11.O into the programs which
are to be run with piping, having 'pipe_set(&argc,argv)' as the
first executable statement, and 'pipe_exec()' as the last
executable statement. The files 'pipe.in' and 'pipe.out' are
used to redirect stdin and stdout, with appropriate housekeeping.
I actually redirect to out of the way user areas such as
'15/m:pipe.in' on a RAM drive, since everything is then much
faster. 'AZPIPE11.C' can be edited and recompiled as necessary
to accomodate this sort of thing. A path search scheme can be
specified for each program after the first '|' character by
editing the 'path' array of strings and recompiling. As it is
now, the path is '00/A:', '00/B:', '00/C:', '00/D:', and '00/E:'.
Without a doubt, the proper way to do this job is through the
operating system, rather than these program add-ons. But the
price of an extra 4K in the size of typical filter programs
does not seem too much.
On the command line, the '|' character is used to signify a pipe.
It must stand alone, with at least one space separating it from
programs and arguments.
prog1 [args ...] | prog2 [args ...] | prog3 [args ...]
Stdin and stdout can be further redirected for the beginning and
the end of the sequence.
prog1 [args] <input | prog2 [args] | prog3 [args] >output
Note that this redirection, since it is handled initially by the
"inaccessible" Croot() routine, can be specified at any position
of the command line, since Croot(), itself, does not know piping.
Initial stdin and stdout redirection is handled by Croot(), and
the 'pipe_set()' routine backtracks to determine whether stdout
has been redirected or not. If so, pipe_set() takes over and
keeps track of the need to later redirect stdout at the tail of
the pipe sequence. Anyway, the command line
prog1 [args] <input >output | prog2 [args] | prog3 [args]
is then the functional equivalent of the previous command line.
In detail, this operation is accomplished by adding at the end
of the argument list an argument starting with a 'reserved'
character ('^'), which indicates to pipe_exec() that it is to
redirect stdout at the tail end of the piping.
*****************************************************************
Version 1.1 fixes a couple of bugs and implements path searching
(very convenient) and ZCPR-style DU: specifications, as well as
preserving the Aztec-style U/D: protocol.
Bob Presswood
Inquiries via GENIE to R.PRESSWOOD