From owner-freebsd-standards@FreeBSD.ORG Sat Apr 4 19:26:20 2009 Return-Path: Delivered-To: standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66B371065679; Sat, 4 Apr 2009 19:26:20 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from viefep19-int.chello.at (viefep19-int.chello.at [62.179.121.39]) by mx1.freebsd.org (Postfix) with ESMTP id 738298FC13; Sat, 4 Apr 2009 19:26:18 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from edge05.upc.biz ([192.168.13.212]) by viefep16-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090404190924.ONOJ771.viefep16-int.chello.at@edge05.upc.biz>; Sat, 4 Apr 2009 21:09:24 +0200 Received: from lizard.fafoe.narf.at ([213.47.85.26]) by edge05.upc.biz with edge id bX8f1b08c0a5KZh05X8gv8; Sat, 04 Apr 2009 21:09:24 +0200 X-SourceIP: 213.47.85.26 Received: by lizard.fafoe.narf.at (Postfix, from userid 1001) id 7E40BBAF0; Sat, 4 Apr 2009 21:08:39 +0200 (CEST) Date: Sat, 4 Apr 2009 21:08:39 +0200 From: Stefan Farfeleder To: Jilles Tjoelker Message-ID: <20090404190838.GA1352@lizard.fafoe.narf.at> Mail-Followup-To: Jilles Tjoelker , Wesley Shields , standards@freebsd.org References: <20090322144753.GA48259@atarininja.org> <20090322214741.GA50879@stack.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090322214741.GA50879@stack.nl> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Wesley Shields , standards@freebsd.org Subject: Re: FW: shell choice freebsd git port X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 19:26:20 -0000 On Sun, Mar 22, 2009 at 10:47:41PM +0100, Jilles Tjoelker wrote: > On Sun, Mar 22, 2009 at 10:47:53AM -0400, Wesley Shields wrote: > > As the maintainer of devel/git I'd like this port to do the right thing, > > but I'm not sure if this is a legitimate bug in our /bin/sh or not. > > Anyone care to comment on this? > > > ----- Forwarded message from Jeff King ----- > > > Date: Sun, 22 Mar 2009 05:37:10 -0400 > > From: Jeff King > > To: wxs@freebsd.org > > Subject: shell choice freebsd git port > > > Hi, > > > I'm one of the upstream developers of git, and it looks like you are the > > git ports maintainer for FreeBSD. I wanted to discuss an issue which you > > may run into while packaging git 1.6.2.1. > > > It seems that FreeBSD's /bin/sh treats blank lines in an eval as a > > successful command. E.g., (the output is from FreeBSD 6.1, but I built > > the current HEAD from anoncvs and it seems to have the same problem): > > > $ /bin/sh > > $ eval 'false > > > > ' > > $ echo $? > > 0 > > > (whereas bash and dash would print '1'). > > > This is problematic for our test suite, which consists of a lot of > > eval'ing. Failing tests may be missed if their status is ignored, one > > test in 1.6.2.1 which expects a non-zero exit status actually does > > report failure when it actually succeeded. On top of that, some of the > > scripts (like bisect and filter-branch) care about the exit status of > > evals at run-time to determine whether an error occurred. > > > There is some discussion on the git list here: > > > http://thread.gmane.org/gmane.comp.version-control.git/112519/focus=112621 > > > I don't know if you want to do anything to the port to work around this. > > The obvious solution is requiring bash, and setting SHELL_PATH > > appropriately in the Makefile. You may also want to see if anyone is > > interested in treating this like a bug in /bin/sh and fixing it (I > > consider it a bug, but others may consider it historical behavior, I > > suppose). > > As discussed on IRC, I think this is a bug in /bin/sh. > > Just from reading the code, NetBSD does not seem to have fixed this. > > The following patch seems to fix the problem: > http://www.stack.nl/~jilles/unix/sh-eval-emptyline.patch > > Apart from 'eval', also 'trap', 'fc' and strings passed with '-c' are > affected. > > Empty lines inside {}, if or similar constructs are treated differently > and work fine even without the patch. Committed, thanks!