Subprocesses (was: [ANNOUNCE] shell-haskell 1.0.0)

[Simon Marlow]

My humblest aplogies for forgetting about your RunProcess library, Daan!
It was even sitting in my inbox.

If I could be allowed to summarise: the idea is to provide

  createPipe :: IO (Handle,Handle)

which is then used with the existing Posix.runProcess to provide
functionality like launch, but in a more general way since you have the
option to create pipes or not.

Cheers,
	Simon

> -----Original Message-----
> From: Daan Leijen [mailto:daan@cs.uu.nl]=20
> Sent: 09 May 2003 11:46
> To: Simon Marlow; libraries@haskell.org
> Subject: Re: Subprocesses (was: [ANNOUNCE] shell-haskell 1.0.0)
>=20
> Hi all,
>=20
> I have implemented a generalised library for communicating=20
> with child processes some
> time ago for windows (but it is easy to implement for unix's=20
> too).  I believe that
> the interface encompasses all current mechanism around =20
> (system, runProcess, popen, launch).
>=20
> Basically, it allows one to create pipes in Haskell that can=20
> be read and written just like
> normal file "Handle"s. Furthermore, you can start a child=20
> process that can get its stdin, stdout,
> and stderr redirected to one of those pipes. This=20
> "runProcess" call is basically the same to
> "Posix.runProcess".
>=20
> I have attached the documentation and description of the=20
> functions to this mail in HTML format.
> It also contains an example of a "spawn" function that=20
> closely resemebles the "launch" function
> of shell-haskell.
>=20
> I think that this interface is a good starting point for a=20
> discussion on the final library interface
> for sub-processes.
>=20
> All the best,
>   Daan.
>=20
>=20
> ----- 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)
>=20
>=20
> > 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=20
> 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=20
> communicate with
> >     the subprocess using these Handles.).
> >
> >   - POpen.popen (can specify an input String, and gives you=20
> lazy output
> >     Strings.  No interactive communication is possible.)
> >
> > Ok, *three* ways.  System.Cmd.system, Posix.runProcess,=20
> POpen.popen, and
> > shell-haskell.  Er.  *Four* ways.
> >
> > David Sankel's shell-haskell creates pipes for=20
> stdin/stdout/stderr, and
> > lets you communicate interactively with the sub-process via=20
> Handles.  It
> > could do with a way to specify the environment and working=20
> directory of
> > the sub-process (ala POpen and runProcess), but apart from=20
> that it seems
> > to be the most flexible of the four.  It could be=20
> simplified slightly by
> > using one Handle rather than two for stdin/stdout.
> >
> > We should think about what functionality we want to provide=20
> in the core
> > libraries.  My preference would be to go for a full version=20
> 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=20
> [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
> >
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > shell-haskell 1.0.0
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >
> >   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
> >
> >
> >
>=20
>=20