On Mar 10, 2009, at 7:17 PM, Jeff King wrote:
Show 58 quoted lines
> 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.
Tomas Carnecky <tom@dbservice.com>