[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: grep-3.4-almost.19-ff30 on Solaris 10
From: |
Bruno Haible |
Subject: |
Re: grep-3.4-almost.19-ff30 on Solaris 10 |
Date: |
Fri, 18 Sep 2020 11:01:54 +0200 |
User-agent: |
KMail/5.1.3 (Linux/4.4.0-189-generic; KDE/5.18.0; x86_64; ; ) |
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