Re: interrupt causes parse error in configure script

[Ralf Wildenhues]

* Jim Meyering wrote on Mon, Aug 18, 2008 at 03:59:18PM CEST:
> Ralf Wildenhues <address@hidden> wrote:
> 
> > Maybe all you want to prevent is errors from inside the trap code?
> 
> No, I want to avoid the parse error.

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

  # The following gives an error if gl_cv_XXX has not been set:
  # Yes, the omission of double quotes is *on purpose*, because
  # each time 'test' gives an error here, it means the long
  # computation above has a logic error.
  if test $gl_cv_XXX ...; then
    ...
 

So, each time we encounter an undefined variable, we actually find a
logic error in a configure macro.  Nice side effect!

Your patch papers over all those bits.

So, let's see what you actually encounter.  When you hit ^C, then the
normal code during some configure test, should not be executed any more
anyway, only trap code should be executed.  Consequently, "fixing"
AC_CHECK_FILE, AC_CHECK_DECL, AC_CHECK_FUNC (haven't checked further)
should be moot anyway: they are never used in the trap code.

So the errors you see can be result of two things:

- Missing quoting in the trap code.  This should be fixed, if any.

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

In order to be able to analyze, it would be nice to have example
configure scripts where this happens, plus shell, system.

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

Cheers,
Ralf