From owner-freebsd-current@FreeBSD.ORG Wed Jun 25 09:49:19 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 39ABE37B401; Wed, 25 Jun 2003 09:49:18 -0700 (PDT) Received: from kientzle.com (h-66-166-149-50.SNVACAID.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A38D43F85; Wed, 25 Jun 2003 09:49:17 -0700 (PDT) (envelope-from kientzle@acm.org) Received: from acm.org (big.x.kientzle.com [66.166.149.54] (may be forged)) by kientzle.com (8.12.9/8.12.9) with ESMTP id h5PGnAtJ083830; Wed, 25 Jun 2003 09:49:10 -0700 (PDT) (envelope-from kientzle@acm.org) Message-ID: <3EF9D31F.6010401@acm.org> Date: Wed, 25 Jun 2003 09:51:43 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John-Mark Gurney References: <20030624183515.A42570@FreeBSD.org> <1056499632.662.7.camel@timon.nist> <3EF922BE.4070803@acm.org> <20030624234707.A59666@FreeBSD.org> <20030625001525.A60867@FreeBSD.org> <20030625060450.GX57612@funkthat.com> <20030625074151.GY57612@funkthat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Juli Mallett cc: Andrey Chernov cc: freebsd-current@freebsd.org cc: "Tim J. Robbins" Subject: Re: tcsh being dodgy, or pipe code ishoos? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: kientzle@acm.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2003 16:49:19 -0000 John-Mark Gurney wrote: > ok, with some magic ktrace work, I have come up with an more complete > answer to the riddle. It's how the shell exec's the processes. The > bare cause can be demo'd by: > >>( ( echo 2 ; echo 3 ) | ./xargs -I% echo + % ) > > > Say the shell you run the above command is 10. It will fork to create > a shell to run the commands in the outter parens. Call this 11. 11's > job is to run: (echo 2; echo 3) | ./xargs -I% echo +% > 11 will fork/exec and run: echo 2; echo 3 creating process 12. 11 > will see that there is no additional commands after ./xargs, and > exec (not fork) xargs. Since 12 is stil around and a child of 11, > when it exits, 11 will reap 12, and thinking that the first proccess > has exited, run the second echo command. Due to scheduling, we'll > have two processes running at the same time which can cause the > interleaving of data. > > So, now the question is, do we fix xargs to deal with unexpected > children? Or fix the shells in question? (tcsh and zsh seem to suffer > this problem) > > To me, fixing xargs is correct since it prevents another possible > future abusers of this "feature". Good work! Congratulations on figuring that one out. It's probably best to fix both. Fixing xargs basically involves keeping a list of child PIDs and checking harvested children against that list. If the child wasn't spawned by xargs, it should just ignore it (in particular, not decrement curprocs). Not entirely trivial, but not a lot of work, either. Fixing the shell would also be desirable, as Terry points out, though it does involve removing a nice optimization. Why do exec-ed processes inherit the children of the former process, anyway? That doesn't entirely sound right to me. Is that behavior mandated by some standard? If not, this could arguably be considered a kernel bug. Hmmm... Tim Kientzle