Simon Marlow wrote:
> >> I think this covers most of the useful situations. If you want to do
> >> the same thing in both parent and child, or handle in the parent and
> >> SIG_DFL in the child: use runProcess. If you want to ignore in the
> >> parent and SIG_DFL in the child: use System.Cmd.{s
On 02 February 2005 14:39, Glynn Clements wrote:
> Simon Marlow wrote:
>> I think this covers most of the useful situations. If you want to do
>> the same thing in both parent and child, or handle in the parent and
>> SIG_DFL in the child: use runProcess. If you want to ignore in the
>> parent a
Simon Marlow wrote:
> I've now fixed system and rawSystem to do something more appropriate on
> POSIX systems: they now disable SIGINT and SIGQUIT in the parent, and
> reset these signals to SIG_DFL in the child. This isn't completely
> correct, but it's better than before.
Just a reminder, as
On 27 October 2004 15:08, Glynn Clements wrote:
> Simon Marlow wrote:
>
>> So basically you're saying that if runProcess is to be used in a
>> system()-like way, that is the parent is going to wait synchronously
>> for the child, then the parent should be ignoring SIGQUIT/SIGINT.
>> On the other
Simon Marlow wrote:
> So basically you're saying that if runProcess is to be used in a
> system()-like way, that is the parent is going to wait synchronously for
> the child, then the parent should be ignoring SIGQUIT/SIGINT. On the
> other hand, if runProcess is going to be used in a popen()-li
My apologies if I misinterpreted your comments. There appear to be some
use cases and conventions here that I'm not altogether familiar with.
So basically you're saying that if runProcess is to be used in a
system()-like way, that is the parent is going to wait synchronously for
the child, then t
