Shouldn't System.Process.runInteractiveCommand close inherited descriptors above 2?

[Tomasz Zielonka]

On Mon, Jun 04, 2007 at 01:08:11PM -0700, Bryan O'Sullivan wrote:
> Tomasz Zielonka wrote:
> 
> >Additionaly, in a complex
> >application you may want a particular descriptor to be passed through
> >one exec(), and not passed through another.
> 
> Well, you have all the building blocks you need to write a function that 
> will do just that.  It shouldn't take more than a few lines of code.

You mean using System.Posix?

Writing our version of runInteractiveProcess in the same way as the
official one would mean writing much more than a few lines of code.
The official implementation does much of its work through FFI. I wonder
why it doesn't use System.Posix more...  Did it lack efficiency or
functionality?

Anyway, we will rather use an external wrapper program - that should be
enough for us.

> >So my initial question changes to: would it be useful to have an
> >extended version of runInteractiveProcess with options for using
> >non-standard behaviour and things like setsid(2)? Did anyone other
> >than us wanted such functionality?
> 
> If you want to manipulate sessions and stuff like that, you're deep in 
> application-specific territory, not to mention POSIX specificity.  The 
> libraries already provide the basic pieces that you need; I don't see 
> much value in cooking some particular combination of them into a 
> "blessed" library function.

I guess you are right. But now I wonder if it would be possible to make
it easier to create such special versions of those functions. Building
them from the primitives probably doesn't take much code, but certainly
requires care and knowledge of many details. Maybe some kind of a
combinator library could help here, but this is only a vague idea right
now.

Best regards
Tomek