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