From owner-freebsd-current Mon Jul 16 8:27:29 2001 Delivered-To: freebsd-current@freebsd.org Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.121.49]) by hub.freebsd.org (Postfix) with ESMTP id 7F01B37B405 for ; Mon, 16 Jul 2001 08:27:24 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.130.87.Dial1.SanJose1.Level3.net [209.245.130.87]) by scaup.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id IAA04107; Mon, 16 Jul 2001 08:26:53 -0700 (PDT) Message-ID: <3B5307E2.6E26B445@mindspring.com> Date: Mon, 16 Jul 2001 08:27:30 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Garrett Wollman Cc: Giorgos Keramidas , freebsd-current@FreeBSD.ORG Subject: Re: cannot print to remote printer References: <873d83pquy.wl@wilhelm.noname> <20010711214311.C2855@heechee.tobez.org> <200107120645.f6C6jtP45267@uriah.heep.sax.de> <20010712122148.B10960@heechee.tobez.org> <86k81eaqcj.fsf@hades.hell.gr> <200107122117.f6CLHsl43063@khavrinen.lcs.mit.edu> <3B4F3485.DE6DC3E5@mindspring.com> <20010714014914.A7876@hades.hell.gr> <200107141705.f6EH5c802083@khavrinen.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Garrett Wollman wrote: > > I'm not sure about POSIX, but the manpage of nohup does not mention > > SIGCHLD. The only signals I see mentioned in revision 1.8 of nohup.1 > > are SIGHUP and SIGQUIT. > > That is correct. SIGCHLD is entirely irrelevant to `nohup', as the > slightest amount of effort on Terry's part would have made clear. This is the answer I was asking for: is SIGCHLD "special", and thus treated differently, or is this applicable to all signals? I would be alarmed, if we were to treat different signals differently, which it seems you are advising. The reason I mentioned "nohup" is that the behaviour you are specifying, if applied to SIGHUP as well as SIGCHLD, would break "nohup". So if "nohup" is intended to continue to function as it has historically, then this change appears pretty arbitrary; at the very least, it complicates the signals API domain specific knowledge required to use the thing, which is annoying, to say the least. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message