On 20 Jan 2010, at 09:25, Derek Zhou wrote: > 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.
I don't think you can infer anything about what the behavior should be from whether the 'parent is on a tty'. >>> 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. I think the background process is stopped if it tries to *read*, not if it tries to write. I also strongly suspect that this is the behavior expected by most people ... if background processes were freely able to read from the terminal then you would have a conflict between different processes trying to read data. >>> 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. I added code to the testsuite to check this behavior see the last test in base/NSTask/launch.m and the Helpers/processgroup.m program). Running this on OSX deonstrates that OSD *does* change the process group of processes launched from NSTask, so it looks like the current behavior is correct. > But the following program should illustrate the problem: I think you forgot to add it. _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
