Mail Archives: djgpp-workers/2001/09/11/03:50:11
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 -