From owner-freebsd-current Sat May 23 10:55:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA03639 for freebsd-current-outgoing; Sat, 23 May 1998 10:55:38 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA03575 for ; Sat, 23 May 1998 10:55:27 -0700 (PDT) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id DAA02639; Sun, 24 May 1998 03:54:09 +1000 Date: Sun, 24 May 1998 03:54:09 +1000 From: Bruce Evans Message-Id: <199805231754.DAA02639@godzilla.zeta.org.au> To: bde@zeta.org.au, brian@Awfulhak.org Subject: Re: **HEADS UP** user-ppp has changed ! Cc: archie@whistle.com, freebsd-current@FreeBSD.ORG, julian@whistle.com Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> Access to a controlling terminal is revoked when its controlling process >> goes away. See kern_exit.c. > >Is there any way of avoiding this ? Perhaps relinquishing terminal >control up front, *then* passing the descriptor ? Releasing a controlling terminal earlier just gives a dead descriptor earlier. Session leaders can switch the controlling tty (hopefully only when switching is secure). >The only other alternative is to keep a `/bin/cat' running - in which >case I may as well do the `two /bin/cat' approach.... that way they >get a SIGPIPE when something goes wrong and everything dies nicely. Why would cat be the controlling process? I'm not sure what the controlling process is here. If it's a login shell, then don't kill it. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message