Re: zpty non-functional?

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Aug 24, 10:48pm, Peter Stephenson wrote:
}
} Hmm... this is well outside my comfort zone.  I thought the following
} existing code:
} 
} #ifdef TIOCSCTTY
} 	ioctl(slave, TIOCSCTTY, 0);
} #endif
} 
}        TIOCSCTTY int arg
}               Make  the given terminal the controlling terminal of the calling
}               process.
} 
} But it apparently doesn't

It makes the terminal the controlling terminal, but it doesn't make the
process the group leader for that terminal.  I suspect we also need the

	ioctl(slave, TIOCSPGRP, mypid);

[or equivalent, e.g. tcsetpgrp()] that attachtty() is doing.  I'm a bit
surprised that calling attachtty() works, because it relies on SHTTY
having been set to the right thing, and I don't see that anything in
zpty.c is making sure that slave and SHTTY refer to the same fd; but
perhaps it always is for some indirect reason ...

Is it safe/reasonable to add

	SHTTY = slave;

right before the attachtty() call in your patch?

} The following is after the setsid() (or setpgrp() if that fails or
} doesn't exist).  Maybe it should be conditional on one of those
} succeeding (and do we *really* want to do setpgrp() if setsid() fails,
} even with a warning)?  Or maybe I'm missing the point entirely and just
} got lucky?

The manual page for setsid says:

    The only error which can happen is EPERM. It is returned when the
    process group ID of any process equals the PID of the calling
    process. Thus, in particular, setsid fails if the calling process is
    already a process group leader.

A check of the setpgrp() manual page indicates pretty much the same thing;
there is no defined error that can result from setprp(0L, getpid()); the
only errors are from attempting to set the process group of a different
process than the caller.

So only some completely unexpected error (interrupted system call?) could
cause setsid() to fail, in which case trying again with setpgrp() is no
worse off.