Sigh, I just realised you need to have the stylesheet
to see the documentation properly --- so here is a new
version with the style sheet inlined.
 
-- Daan.
----- Original Message -----
From: Daan Leijen
To: Simon Marlow ; libraries@haskell.org
Sent: Friday, May 09, 2003 12:45 PM
Subject: Re: Subprocesses (was: [ANNOUNCE] shell-haskell 1.0.0)

Hi all,

I have implemented a generalised library for communicating with child processes some
time ago for windows (but it is easy to implement for unix's too).  I believe that
the interface encompasses all current mechanism around  (system, runProcess, popen, launch).

Basically, it allows one to create pipes in Haskell that can be read and written just like
normal file "Handle"s. Furthermore, you can start a child process that can get its stdin, stdout,
and stderr redirected to one of those pipes. This "runProcess" call is basically the same to
"Posix.runProcess".

I have attached the documentation and description of the functions to this mail in HTML format.
It also contains an example of a "spawn" function that closely resemebles the "launch" function
of shell-haskell.

I think that this interface is a good starting point for a discussion on the final library interface
for sub-processes.

All the best,
  Daan.


----- Original Message -----
From: "Simon Marlow" <simonmar@microsoft.com>
To: <libraries@haskell.org>
Sent: Friday, May 09, 2003 12:03 PM
Subject: Subprocesses (was: [ANNOUNCE] shell-haskell 1.0.0)


> Libraries people,
>
> There are currently two ways to create and communicate with external
> processes:
>
>   - System.Cmd.system  (very basic, doesn't give you access to the
>     process's output but you can use shell primitives to redirect its
>     input/output).
>
>   - Posix.runProcess (can specify Handles for the process's
> input/output,
>     but it doesn't create pipes so you can't actually communicate with
>     the subprocess using these Handles.).
>
>   - POpen.popen (can specify an input String, and gives you lazy output
>     Strings.  No interactive communication is possible.)
>
> Ok, *three* ways.  System.Cmd.system, Posix.runProcess, POpen.popen, and
> shell-haskell.  Er.  *Four* ways.
>
> David Sankel's shell-haskell creates pipes for stdin/stdout/stderr, and
> lets you communicate interactively with the sub-process via Handles.  It
> could do with a way to specify the environment and working directory of
> the sub-process (ala POpen and runProcess), but apart from that it seems
> to be the most flexible of the four.  It could be simplified slightly by
> using one Handle rather than two for stdin/stdout.
>
> We should think about what functionality we want to provide in the core
> libraries.  My preference would be to go for a full version with three
> pipes (like shell-haskell) and perhaps one or two more specialised
> versions covering common cases (I don't know what these should be,
> though).
>
> What do people think?
>
> Cheers,
> Simon
>
> -----Original Message-----
> From: haskell-admin@haskell.org [mailto:haskell-admin@haskell.org] On
> Behalf Of David Sankel
> Sent: 06 May 2003 03:06
> To: haskell@haskell.org
> Subject: [ANNOUNCE] shell-haskell 1.0.0
>
> ===================
> shell-haskell 1.0.0
> ===================
>
>   shell-haskell provides utilities to communicate with
> other process's via Haskell code.  This library can be
> used for something as simple as getting the output of
> another program or as complex as interacting with an
> interpreter.
>
> see
>
>   http://www.electronconsulting.com/shell-haskell
>
> for details.
>
> David J. Sankel
> _______________________________________________
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>
>
> _______________________________________________
> Libraries mailing list
> Libraries@haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
>