Re: potential bash-specific bug in `tests/defs.in'

[Stefano Lattarini]

At Saturday 22 August 2009, Ralf Wildenhues <address@hidden> 
wrote:
> Hello Stefano,
>
> thanks for the bug report.
>
> * Stefano Lattarini wrote on Fri, Aug 21, 2009 at 01:34:58AM CEST:
> > In these days, I've been playing with the automake source code
> > (just to "instruct" myself by seeing how a real-word, working
> > sotfware is done),
>
> Depending on what your software aims to do, the Automake package
> may not be a great example: it doesn't build any compiled code, for
> example, and as such can avoid a lot of the associated complexity.
>
Well, I'm most interested in exploring the testsuite, as you might 
have guessed :-)
And I'm founding this exploration quite useful for my purposes.
>
> [CUT]
>
> > This bug shouldn't manifest itself frequently (after all, how
> > often does someone write a testcases containing an unseen syntax
> > error?), but can be potentially harmful, making a broken test to
> > be considered as passed.
>
> Ouch, that's not good.  Have you reported this with the bash
> maintainers yet (bug-bash at gnu.org) or is it already fixed in a
> newer release or patch version?
I reported the bug, and the bash maintainer agreed that it's worth
have it fixed in the next version of bash (4.1).
You can find the thread here:
http://lists.gnu.org/archive/html/bug-bash/2009-08/msg00053.html
>
> [CUT]
>
> > I'm aware that, strictly speaking, this is a bug of bash, but
> > since the automake testsuite try to use "portable shell code"
> > only, I think it would be good if it works around that bug,
> > as it does with bugs and limitations of other shells.
>
> First off, I typically do run changed or new tests at least once in
> verbose mode before committing, inspecting all output, which should
> catch the worst blunders of this kind at least for the shell
> tested. If you've found any missed ones, please report them.
I found no test script with syntax errors. In fact, on my system
(debian unstable), the testsuite passes even when I force the
test scripts to be run by dash.
>
> Possible workarounds for this issue:
>
> 1) enhance our "whether /bin/sh has working 'set -e' with exit
> trap" configure test to disable -e for bash (which would then fail
> to catch quite a few possible error cases),
> 2) do nothing (and hope that syntax errors will be found when
> testing with other shells,
> 3) use a patch like below as a workaround, which requires adding
> 'Exit 0' at the end of all tests.
>
> Currently, I still have a slight preference for (2), but may go for
> (3) in the end.
>
> Thanks,
> Ralf
>
Thank you for your consideration.

Regards,
    Stefano