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
