Date: Sun, 22 Mar 2009 22:47:41 +0100 From: Jilles Tjoelker <jilles@stack.nl> To: Wesley Shields <wxs@FreeBSD.org> Cc: standards@freebsd.org Subject: Re: FW: shell choice freebsd git port Message-ID: <20090322214741.GA50879@stack.nl> In-Reply-To: <20090322144753.GA48259@atarininja.org> References: <20090322144753.GA48259@atarininja.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <peff@peff.net> ----- > Date: Sun, 22 Mar 2009 05:37:10 -0400 > From: Jeff King <peff@peff.net> > 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. -- Jilles Tjoelker
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090322214741.GA50879>