X-Authentication-Warning: delorie.com: mail set sender to djgpp-workers-bounces using -f
X-Recipient: djgpp-workers AT delorie DOT com
Date: Mon, 14 Sep 2009 20:56:32 +0300
From: Eli Zaretskii <eliz AT gnu DOT org>
Subject: Re: [PATCH 1/4] DJGPP fix: Do not redirect standard input in configure scripts.
In-reply-to: <4AAE2D0E.5090400@byu.net>
X-012-Sender: halo1 AT inter DOT net DOT il
To: Eric Blake <ebb9 AT byu DOT net>
Cc: autoconf-patches AT gnu DOT org, rugxulo AT gmail DOT com, rrt AT sc3d DOT org,
   djgpp-workers AT delorie DOT com
Message-id: <834or5z9yn.fsf@gnu.org>
References: <20090913191226 DOT GA29257 AT gmx DOT de> <20090913191426 DOT GB29257 AT gmx DOT de> <4AAE2D0E DOT 5090400 AT byu DOT net>
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> Date: Mon, 14 Sep 2009 05:46:22 -0600
> From: Eric Blake <ebb9 AT byu DOT net>
> 
> > -exec AS_ORIGINAL_STDIN_FD<&0 </dev/null AS_MESSAGE_FD>&1
> > +test -n "$DJGPP" || exec AS_ORIGINAL_STDIN_FD<&0 </dev/null
> > +exec AS_MESSAGE_FD>&1
> 
> Since /dev/null is faked as a regular file, is there some better thing we
> can use to achieve the same effect, rather than disabling the redirection
> entirely?  Or, put another way, is NUL always available on DJGPP?

NUL is available on DJGPP, but I don't think this will help.  We are
talking about the following line in the configure script, right?

   exec 7<&0 </dev/null 6>&1

If so, then even replacing /dev/null with NUL (which DJGPP does
automatically under the hood, btw) still causes Bash to barf thusly:

   configure: redirection error: Bad file descriptor (EBADF)

So there's some other factor at work here, not /dev/null.

AFAIU, this redirection is for the rare situation that the script
somehow invokes interactive commands, which will then wait for an
EOF.  So I think replacing it with just

   exec 6>&1

is good enough (I did that in gdb/config/djgpp/config.sed for GDB),
and I believe the proposed patch does just that.

(If I'm barking up the wrong tree, please tell what does this code
generate in the configure script, and I will look again.)