[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

AS_IF breakage (was: AC_TRY_COMPILE() annoyances with 2.63b)

From: Eric Blake
Subject: AS_IF breakage (was: AC_TRY_COMPILE() annoyances with 2.63b)
Date: Tue, 14 Apr 2009 15:39:33 +0000 (UTC)
User-agent: Loom/3.14 (

Eric Blake <ebb9 <at>> 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 $?'

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 

and correctly echo 0.


> 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:

[else as_fn_set_status $?

or revert today's patch to the simpler


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]