Hello Paolo, all, This is a few days old:
* Paolo Bonzini wrote on Fri, Oct 05, 2007 at 11:17:19AM CEST: > Here is what I could gather from reports on [EMAIL PROTECTED] In > particular http://www.mail-archive.com/[EMAIL PROTECTED]/msg15966.html > suggested me the following minimal reproducer > > test -n "${ZSH_VERSION+set}" && emulate sh > failure1 () { > (exit 1) > echo $? > } > > failure2 () { > (exit 1) > } > > failure1 > > failure2 > echo $? > > yielding two 1's on bash and two 0's on zsh. [...] > +Shell functions are considered portable nowadays, though Autoconf > +still does not use them (Autotest does). However, inside a shell > +function you should not be using @code{$?} to check the return code > +of a subshell invocation; in general, since the caller of a shell > +function might look at the function's return code, make sure that the > +last statement of a shell function does not invoke a subshell. Well, the above example shows that it's not just the last statement of a shell function that's interesting: in failure1 the second-to-last statement is buggy. > +Using subshells triggers bugs in zsh 4.x; while Autoconf tries > +to find a shell that does not exhibit the bug, zsh might be the > +only shell present on the user's machine. The zsh bug, as described above, is awfully general; let's see if we can get it a bit more precise before I audit all of ltmain.m4sh. On GNU/Linux with zsh 4.2.5, which has the bug above: - If I replace `exit 1' with `false' or `/bin/false', then the test suddenly works, i.e., this correctly prints two 1's: test -n "${ZSH_VERSION+set}" && emulate sh failure1 () { (false) echo $? } failure2 () { (false) } failure1 failure2 echo $? - If I omit $? and instead use && or || to test the return value, then zsh is stilly buggy: two `bad's with test -n "${ZSH_VERSION+set}" && emulate sh failure1 () { (exit 1) && echo bad } failure2 () { (exit 1) } failure1 failure2 && echo bad So it seems the `exit' builtin is to blame. Then I tested a few other builtins at random. The status of `trap' seems unreliable, too. So then I tested other versions, on some systems. There was no variance wrt. system, only version: good versions: - zsh 4.0.6 - zsh 4.3.4 bad versions: - zsh 4.2.0 - zsh 4.2.4 - zsh 4.2.5 - zsh 4.2.6 I did not find a 4.1.x nor 4.3.0 to try out, and haven't built from CVS. OK to apply this patch? Thanks, Ralf 2007-10-15 Ralf Wildenhues <[EMAIL PROTECTED]> * doc/autoconf.texi (Portable Shell): Improve description of zsh 4.x function subshell bug with exit and trap. diff --git a/doc/autoconf.texi b/doc/autoconf.texi index addb7b1..ded0f67 100644 --- a/doc/autoconf.texi +++ b/doc/autoconf.texi @@ -11976,15 +11976,13 @@ that are not found in all Bourne-compatible shells; restrict yourself to the lowest common denominator. Even @code{unset} is not supported by all shells! -Shell functions are considered portable nowadays, though Autoconf -still does not use them (Autotest does). However, inside a shell -function you should not be using @code{$?} to check the return code -of a subshell invocation; in general, since the caller of a shell -function might look at the function's return code, make sure that the -last statement of a shell function does not invoke a subshell. -Using subshells triggers bugs in zsh 4.x; while Autoconf tries -to find a shell that does not exhibit the bug, zsh might be the -only shell present on the user's machine. +Shell functions are considered portable nowadays, though Autoconf still +does not use them (Autotest does). However, inside a shell function, +you should not rely on the error status of a subshell if the last +command of that subshell was @code{exit} or @code{trap}, as this +triggers bugs in zsh 4.x; while Autoconf tries to find a shell that +does not exhibit the bug, zsh might be the only shell present on the +user's machine. Some ancient systems have quite small limits on the length of the @samp{#!} line; for instance, 32
