Re: interrupt causes parse error in configure script

[Eric Blake]

Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de> writes:

> We are talking past each other.  I'm arguing that the parse error is
> typically helpful, not harmful.
> 
> Bruno does in several places in gnulib:
> 
>   # Long computation that sets gl_cv_XXX
>   ...
>   if test $gl_cv_XXX ...; then
>     ...

There's a difference between:

gl_cv_XXX=...
if test $gl_cv_XXX = ...; then

and what Jim is attempting to fix:

if test `...` = ...; then

It appears that what Jim is seeing is that the shell (which one?) catches the 
Ctrl-C, aborts the subshell, but then proceeds with execution of the builtin 
test before quitting the script.  In other words, the Ctrl-C is not properly 
affecting the parent shell.

> 
> - Bugs in the shell.  These should be analyzed, reported upstream,
>   documented in the shell portability section in the manual.  Only
>   *then*, when we know exactly what we're dealing with, can we start
>   putting workarounds in place.

I think we can factor it into a simpler testcase.  I just tried this:

$ bash -c 'if test `sleep 5; echo hi` = hi ; then echo yes; fi'
^C
$ ash -c 'if test `sleep 5; echo hi` = hi ; then echo yes; fi'
^C
$ zsh -c 'if test `sleep 5; echo hi` = hi ; then echo yes; fi'
^C
$ ksh -c 'if test `sleep 5; echo hi` = hi ; then echo yes; fi'
^Cksh: test: hi: unexpected operator/operand

So it looks like my copy of ksh (pdksh 5.2.14) suffers from the bug.  I agree 
with Ralf that this needs documentation first.

But it looks like we now know the workaround:

$ ksh -c 'if foo=`sleep 5; echo hi`; test $foo = hi ; then echo yes; fi'
^C

> 
> Beside, the AS_VAR_YES interface is ugly, but that's orthogonal.

And based on the usage pattern, maybe an interface like this would be nicer:

AS_VAR_IFELSE(var, [value = yes], if-true, if-false)

than

AS_IF([AS_VAR_YES(var, value)], if-true, if-else)

-- 
Eric Blake