Quoth "Stephen Hicks" <[EMAIL PROTECTED]>:
> In general, given a handful of system calls (and/or
> read/write handles), is there a way to combine them all together?
Well, sure - if I understand what you mean. Not "Handles", in the
sense of a Haskell library construct, but UNIX pipes and processes
are reasonably simple to work with in a general purpose programming
language.
I'm sorry to say the following isn't real code, since GHC doesn't
run on the platform I'm using to write this mail, but I hope it will
serve to demonstrate the principles using bare UNIX system calls,
and that it doesn't contain any serious errors.
forkProcess $ do -- pipe tail
(pa0, pa1) <- createPipe
-- Command exec'd in this fork reads from this pipe,
-- so dup 0 (input) from pipe input fd. Both ends of
-- pipe will be inherited by child forks.
dupTo pa0 0
forkProcess $ do -- first pipe head
-- Command exec'd in this fork writes to parent's pipe.
dupTo pa1 1
-- Close parent's pipe so fds won't be inherited by
-- next fork.
closeFd pa0
closeFd pa1
forkProcess $ execFile "/bin/df" ... -- second pipe head
execFile "/bin/df" ...
-- Close own pipe write end, so child process exit(s) will cause EOF
closeFd pa1
execFile "/usr/bin/sort" ...
Key points:
Input, output and error are file descriptors 0, 1 and 2,
by definition (pronounced "unit 0", etc.)
dupTo (UNIX system call dup2()) duplexes an I/O stream, so
"dupTo p0 0" sets up a pipe for a standard UNIX command
that reads from unit 0.
Reads from the pipe's read fd will either return data or block,
until exit of the *last* process with the pipe's write end open.
Hence the importance of closing the write end of your own pipe,
and not letting pipe fds "leak" into child processes.
Donn Cave, [EMAIL PROTECTED]
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
