On Sun, Mar 08, 2009 at 12:45:55PM -0700, Junio C Hamano wrote:

quoted text
> If this part from your analysis is true for a shell:
> 
> > eval 'false
> >
> > '
> > echo status is $?
> >
> > generates:
> > ...
> >   status is 0
> 
> I would be very tempted to declare that shell is unfit for any serious
> use, not just for test suite.  Removing the empty line at the end of a
> scriptlet that such a broken shell misinterprets as an empty command
> that is equivalent to ":" (or "true") might hide breakages in the test
> suite, but
> 
>  (1) eval "$string" is used outside of test suite, most notably "am" and
>      "bisect".  I think "am"'s use is safe, but I wouldn't be surprised if
>      the scriptlet "bisect" internally creates has empty lines if only for
>      debuggability; and more importantly
> 
>  (2) who knows what _other_ things may be broken in such a shell?

OK, good points. I was just hoping not to cause people on FreeBSD undue
pain. What is the best way to make such a declaration? I can think of:

  1. A mention in the release notes.

  2. A test in the Makefile similar to the $(:) test.

  3. Getting in touch with the freebsd ports maintainer for git and
     suggesting a dependency on bash (and/or seeing if he wants to push
     through a fix for /bin/sh).

     I don't know if the same problem exists on other BSD-influenced systems,
     or how closely they share the ports collection (it's been quite a
     while since I've really admin'd a freebsd box). For that matter, I
     wonder if this is also a problem on OS X. Can somebody with an OS X
     box try:

       $ /bin/sh
       $ eval 'false

         '
       $ echo $?

     It should print '1'; if it prints '0', the shell is broken.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html