From owner-freebsd-current Wed Feb 24 14:14:32 1999 Delivered-To: freebsd-current@freebsd.org Received: from gilgamesch.bik-gmbh.de (gilgamesch.bik-gmbh.de [194.233.237.194]) by hub.freebsd.org (Postfix) with ESMTP id E475C12313 for ; Wed, 24 Feb 1999 14:09:22 -0800 (PST) (envelope-from cracauer@gilgamesch.bik-gmbh.de) Received: (from cracauer@localhost) by gilgamesch.bik-gmbh.de (8.9.2/8.7.3) id KAA38608; Wed, 24 Feb 1999 10:08:28 +0100 (MET) Message-ID: <19990224100828.A37788@cons.org> Date: Wed, 24 Feb 1999 10:08:28 +0100 From: Martin Cracauer To: mi@aldan.algebra.com, current@FreeBSD.ORG Subject: Re: sh(1) -- exec vs. fork References: <199902191644.LAA08791@misha.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.1i In-Reply-To: <199902191644.LAA08791@misha.cisco.com>; from Mikhail Teterin on Fri, Feb 19, 1999 at 11:43:59AM -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In <199902191644.LAA08791@misha.cisco.com>, Mikhail Teterin wrote: > I just finished going through a couple of crontabs prepending the > command-lines with ``exec'', when it hit me. > > Can shell itself recognize, there will be no more commands and just > proceed to exec without forking? What would this break? > > This should never, of course, happen in interactive mode... > > The shell's source requires studying, but, may be, a knowledgeable > person can answer right away? FreeBSD's /bin/sh does a forkless exec in some cases, which is why we have the echo -n in /etc/rc: (trap 'exit 1' 2 ; ${script} start ; echo -n) The problem with not forking is that trap handling is being broken. Currently, our /bin/sh eliminates one instance when subshells are started with '(...)', the last command in the brackets is just exec'ed without fork. Example: #! /bin/sh echo $$ ( echo $$ cat ) The subshell replaces the outer instances, the pids echoed are the same. But this will break asynchronous traps (which are not Posix, BTW), hence it doesn't do this for the outermost shell of a shell script: #! /bin/sh echo $$ cat The outer shell still exists when cat is exec'ed. Obviously, while this inconsistent behaviour gets most cases right, it isn't perfect, as seen in the /etc/rc hack above. What is needed here is that the process elimination happens only when no traps are set. I looked into this in September (with help from Tor Egge), we need a count of active traps and if traps are active, don't do subshell elimination. The problem here is that counting active traps isn't that easy. Also, this would only solve the lower half of the problem, that too much elimination happens for subshells. The upper half, that elimination could/should happen for toplevel shells when the last command of a script is being exectued needs more thought. I feel uncomfortable having a shellscript running without a handle to the toplevel controlling shell process. For example, you might want to use it get the whole process group of everything it started. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ BSD User Group Hamburg, Germany http://www.bsdhh.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message