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 -----
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
>
>
>