Date: Tue, 11 Sep 2001 09:49:50 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Tim Van Holder 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: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 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.