delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2001/09/11/03:50:11

Date: Tue, 11 Sep 2001 09:49:50 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Tim Van Holder <tim DOT van DOT holder AT pandora DOT be>
cc: djgpp-workers AT delorie DOT com, perl5-porters AT perl DOT org
Subject: Re: Win2k + djgpp
In-Reply-To: <1000190227.3781.5.camel@bender.falconsoft.be>
Message-ID: <Pine.SUN.3.91.1010911094337.2127C-100000@is>
MIME-Version: 1.0
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

On 11 Sep 2001, Tim Van Holder wrote:
> Well, if you recall there was an issue where a perl-spawned shell
> script (for example, autoconf when called from autoupdate) could
> do
>   exec 4>config.log
> but any redirection to FD 4 would cause EBADF.

Yes, but I cannot figure out what does this have to do with the test 
program you posted.  To reproduce this failure, a test program should 
have called open/dup/dup2 in a typical redirection paradigm, preferably 
similar to the code that is actually executed by Bash when it sees a
command such as the one above.  Your test program didn't do that, it just 
opened files.

> More recently, autoconf's autom4te perl script fails because it
> runs 'm4 --error-file=foo'; m4 opens foo (getting FD 4 most of the
> time), and any writes to that file are sent into oblivion (the file
> is created, but empty).

That sounds like a different problem: there's no redirection involved in 
this case, as far as I could see in m4's sources.

> Now that I know what to check, I'll try commenting out the closing
> of stdaux and stdprn and see if that has any effect on it.

Even it does have some effect, it still needs to be explained.  I don't 
think Unix programs start with file descriptors 3 and 4 connected to 
anything, do they?  If so, how come this works on Unix?  I think there's 
some other factor at work here, and the best way to find what it is is to 
run the code which fails under a debugger and see what system call fails 
there and why.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019