On Wednesday 20 January 2010 12:15:11 am Richard Frith-Macdonald wrote: > > On 20 Jan 2010, at 07:21, Derek Zhou wrote: > > Here is a simple patch. It just don't setpgrp if the process is on a tty. > > Actually, the patch effects the task's process group setting if the *parent* > task is on a tty. Probably not what was intended. That is what I want to do. If the parent is on a tty, then you either 1, want the task to use the tty too; so you don't want to setpgrp and has it stalled 2, do not want it to use the tty, then you should just redirect the stdin/out/err I can modify the patch so it conditions on both the parent and the child on tty but it miss the cases that the child is opening /dev/tty directly. I think gpg does that to read the password. > > > The current behavior does not make sense; if the child try to read/write > > anything on the tty it will be stopped; and I don't think that's what > > people want. If the goal is to prevent the child from messing with the > > tty one can and should redirect stdin/stdout/stderr of the child. > > > > Furthermore, I think process group only has something to do with the tty > > usage and the signal handling resulting from that, so ideally you do not > > need to call setpgrp unless you are writing a shell or something; it > > is pretty much a no-op in a GUI app or in Windows. Anyway I believe this > > patch is safe and does what I want. > > Looking at the code, the intention of calling setpgrp is clearly to do two > things ... > > 1. detach the task from any controlling terminal (there's a comment to say > this is what's intended) > 2. permit the -interrupt, -terminate, -suspend and -resume methods to control > any subtasks (without it, the current code for these methods is wrong). > > If setpgrp is not called, then the implementation of the other methods for > controlling the task must also be changed. > > However, while the intention of the existing code is fairly clear, it's not > obvious that it's correct... it may well be that the current behavior is NOT > what OSX does. > What we need is a set of a few simple test programs which we can include in > the testsuite and run on OSX (and with gnuste on gnu/linux and bsd and > mswindows) to make sure that we actually have consistent and OSX compatible > behavior. > > I would not like to change/break existing behaviors until/unless we know that > the change is OSX compatible. The only mac I have access do not have a compiler installed. And I don't know how to make an automatic test program since this involve tty and human interaction. But the following program should illustrate the problem:
_______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev