Re: [PATCH] document shell function problems

[Ralf Wildenhues]

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 address@hidden In 
> particular http://www.mail-archive.com/address@hidden/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  <address@hidden>

        * 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