On Jul 26, 2011, at 1:34 PM, Ray Strode wrote: > Hi, > > On Tue, Jul 26, 2011 at 4:02 PM, Jeremy Huddleston <[email protected]> wrote: >> IMO, there is a point to closing stdin aside from the setsid(2). > My point is, it only solves the problem part way.
Well, the problem you are reporting is 2 parted, hence you should have 2 commits. The stdin closing is an issue in its own right and should be a separate patch. You're also assuming that startx(1) is started from a tty. That's not always the case. On darwin, it's usually not started from a tty, and I don't think that I want to do a setsid(2) in that case. Perhaps you should check isatty(2) before doing a setsid(2). I'd be fine with that since it'd be a nop on darwin. stdin is already closed on darwin, so the whole changeset is a nop for us, but I'm more concerned about how this might effect others. The stdin issue is much more obvious, and the setsid(2) issue I feel is a bit more debatable. That's why I suggest you get in the other patch now and we can just focus our discussion on setsid(2). > As an example, say a program wants to ask the user for a password. > The program supports asking the user at the console if run from a tty, > and supports asking the user from an X dialog otherwise. The way that > program would ask the user for a password at the console is by opening > /dev/tty (since password programs don't read input from stdin). That > program could first try to open /dev/tty, and if it fails assume an X > fall back. If you haven't insulated the client from the tty startx > was run on, then this program may end up trying to ask for a password > on some switched away VT! and would probably get suspended instantly > with SIGTTIN. You could argue the client should try X first and fall > back to console. Or you could argue the client should do isatty() on > stdin before trying to open /dev/tty. But both are debatable and this > is just one example, anyway. > > The example serves to show that redirecting STDIN to /dev/null > partially solves the same problem setsid partially solves.That problem > is "detaching X clients from the tty startx was run on". > > Or is there another problem being solved, that you have in mind? > > --Ray > _______________________________________________ > [email protected]: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: http://lists.x.org/mailman/listinfo/xorg-devel > _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
