Re: why does NSTask setpgrp on sub processes?

[Derek Zhou]

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: