Re: grep-3.4-almost.19-ff30 on Solaris 10

[Bruno Haible]

Hi Paul,

> On 9/17/20 1:53 PM, Bruno Haible wrote:
> > -  {
> > -    $1
> > -  } AS_MESSAGE_FD>/dev/null
> > +  exec GL_TMP_FD>&AS_MESSAGE_FD AS_MESSAGE_FD>/dev/null
> > +  $1
> > +  exec AS_MESSAGE_FD>&GL_TMP_FD AS_MESSAGE_FD>&-

I had a typo in here. Corrected:

  exec GL_TMP_FD>&AS_MESSAGE_FD AS_MESSAGE_FD>/dev/null
  $1
  exec AS_MESSAGE_FD>&GL_TMP_FD GL_TMP_FD>&-

Which expands to:

  exec 9>&6 6>/dev/null
  $1
  exec 6>&9 9>&-

> If a trap occurs during $1 and 'configure' outputs something to stderr before 
> it 
> exits, the output could be lost due to this patch.

No, I don't think so. The file descriptor 2 is unaffected by the file descriptor
reshuffle. Only file descriptor 6 is affected, which is the one used by
AC_MSG_CHECKING/AC_MSG_RESULT. No one is supposed to use this file descriptor
in a 'trap' action.

> Looking into it further, gl_SILENT is iffy as a general macro, as discarding 
> stderr could make scripts harder to debug.

I disagree. I want gl_SILENT for the purpose of doing more complex checks inside
an AC_CACHE_CHECK invocation. Without gl_SILENT, the message output dictates the
structure of the AC_CACHE_CHECKs. This is not good.

> Since gl_SILENT is used in just one place in Gnulib

signalblocking.m4 is only the first one. I want gl_SILENT also to clean up
the getaddrinfo output and others.

> fix the issue with gl_SIGNALBLOCKING and cached configuration variables.

While the gl_SIGNALBLOCKING patch is correct, it does not help solving the
general problem that gl_SILENT is meant to address.

Can you please restore it?

Bruno