On Sun, Mar 08, 2009 at 12:45:55PM -0700, Junio C Hamano wrote:
> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
