Eric Blake <ebb9 <at> byu.net> writes: > Sorry for committing before the testsuite completed. It turns out that > this introduced a regression in 'make check TESTSUITEFLAGS="-k > AC_RUN_IFELSE"', due to the following: > > $ if false; then :; else echo $?; fi > 1
In the process of trying to work around this, I discovered a bug in zsh 4.3.9: $ zsh -c 'emulate sh; false; $empty; echo $?' 1 All other shells that I tried obey this POSIX rule [1]: "If there is no command name,... the command shall complete with a zero exit status." and correctly echo 0. [1] http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_0 9_01 > But adding the : after the else, we have effectively made it impossible > for the user to grab $? after the if condition, so I'll have to rethink > this patch. Various things I've tried - the idea here is to replace 'echo $?' with anything else the user might have supplied, including an m4 macro that expands to the empty string: if false; then :; else $empty echo $?; fi This fails to preserve status, except on zsh where it triggered the shell bug mentioned above. if false; then :; else $empty echo $?; fi For simple commands, this works fine. But it inhibits recognition of the word after $empty as a keyword, causing syntax errors if you try to insert a compound command instead of 'echo $?'. nop() { return; } if false; then :; else nop echo $?; fi preserves $? on compliant shells. But this fails on older ash and on Solaris ksh (but surprisingly passed on Solaris /bin/sh). A slight tweak: nop() { return $?; } if false; then :; else nop echo $?; fi and Solaris ksh is happy, but ash still fails. nop() { return $1; } if false; then :; else nop $? echo $?; fi correctly preserves the exit status for all shells I have access to, but it sure adds a lot of characters. On the other hand, the definition for that nop matches as_fn_set_status, which m4sh is already using. So, would we rather write: m4_define([_AS_IF_ELSE], [m4_ifnblank([$1], [else as_fn_set_status $? $1 ])]) or revert today's patch to the simpler m4_define([_AS_IF_ELSE], [m4_ifnblank([$1], [else $1 ])]) which puts the burden back on the user, where calling: AS_IF([false], [], [AC_REQUIRE(...)]) causes a syntax error. If I could get AC_REQUIRE to play nicely with m4_expand, then that would be the solution - pre-expand the user's text, at which point we then know for certain whether the expansion is empty. But right now, I don't know how to pull that trick off. -- Eric Blake
