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 hand, if runProcess is going to be used in a >> popen()-like way, then the parent should not be ignoring >> SIGQUIT/SIGINT. > > Exactly. > >> The current >> interface doesn't allow for controlling the behaviour in this way. > > Yep. > >> So the current signal handling in runProcess is wrong, and should >> probably be removed. What should we have instead? We could >> implement the system()-like signal handling for System.Cmd.system >> only, perhaps. > > Well, probably for system and rawSystem.
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. runProcess and friends don't do any signal handling. 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.{system,rawSystem}. To handle in the parent and ignore in the child: unfortunately not directly supported. I realise this doesn't address the library design issues you raised, but as you pointed out there doesn't seem to be a good platform-independent solution here. Cheers, Simon _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users