From owner-cvs-src@FreeBSD.ORG Mon Aug 15 00:09:08 2005 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 18D2A16A41F; Mon, 15 Aug 2005 00:09:08 +0000 (GMT) (envelope-from brian@Awfulhak.org) Received: from gw.Awfulhak.org (awfulhak.demon.co.uk [80.177.173.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A72E43D45; Mon, 15 Aug 2005 00:09:07 +0000 (GMT) (envelope-from brian@Awfulhak.org) Received: from dev.lan.Awfulhak.org (brian@dev.lan.Awfulhak.org [172.16.0.5]) by gw.Awfulhak.org (8.13.3/8.13.3) with ESMTP id j7F092Dr051585; Mon, 15 Aug 2005 01:09:02 +0100 (BST) (envelope-from brian@Awfulhak.org) Date: Mon, 15 Aug 2005 01:09:00 +0100 From: Brian Somers To: Bob Willcox Message-ID: <20050815010900.6f7e0424@dev.lan.Awfulhak.org> In-Reply-To: <20050814020635.GA19321@luke.immure.com> References: <200508132128.j7DLShWb080387@repoman.freebsd.org> <42FE6A67.6000208@freebsd.org> <20050814020635.GA19321@luke.immure.com> X-Mailer: Sylpheed-Claws 1.9.13 (GTK+ 2.6.9; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on gw.lan.Awfulhak.org Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org, Colin Percival Subject: Re: cvs commit: src/usr.sbin/portsnap/portsnap portsnap.sh X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2005 00:09:08 -0000 On Sat, 13 Aug 2005 21:06:35 -0500 Bob Willcox wrote: > On Sat, Aug 13, 2005 at 02:47:19PM -0700, Colin Percival wrote: > > Colin Percival wrote: > > > This bug was caused by the astonishing interaction of "return" and > > > pipelines; in the following code, the "return" does not exit the > > > function, but instead exits the subshell which was spawned for the last > > > element of the pipeline; consequently, the output produced is "foo". > > > > > > foo() { > > > echo bar | while read baz; do > > > if [ ${baz} = "bar" ]; then > > > return 1 > > > fi > > > done > > > > > > echo foo > > > } > > > > For what it's worth, I don't know if the behaviour of our sh(1) is correct > > here. IEEE 1003.1, 2004 Ed. says > > > > "The return utility shall cause the shell to stop executing the current function > > or dot script. If the shell is not currently executing a function or dot script, > > the results are unspecified." > > > > and I don't see any mention of not returning from a function just because we > > happen to be inside a subshell. > > I tried this on a some different shells. Turns out that bash & pdksh > behave similar to the FreeBSD shell, but with ksh93 the return exits the > function. So maybe ksh93 is the only one working correctly--or it's the > only one that's broke. No. ksh93, aka the original ksh, is documented to execute the last command in a pipeline inline. Other shells don't. This is great for doing things like ``echo $line | read a b c'', and also avoids the unexpected return/exit not returning or exiting problems that Colin has seen. However, traditional Bourne shell scripts have to just handle this sort of weirdness with constructs like get input | while read line do important command || exit 1 other important command || exit 1 done || exit 1 AFAIK POSIX doesn't explicitly say what's right here, but not having the POSIX spec handy, treat that with a pinch of salt!! -- Brian Somers Don't _EVER_ lose your sense of humour !