From: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
To: <djgpp-workers AT delorie DOT com>
Subject: Re: Very strange behaviour in our Perl port (redirection issue?)
Date: Wed, 15 Aug 2001 19:50:24 +0200
Message-ID: <CAEGKOHJKAAFPKOCLHDIMELJCGAA.tim.van.holder@pandora.be>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <2427-Wed15Aug2001121328+0300-eliz@is.elta.co.il>
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

> how does Perl implement the `system' feature.

I'm not sure - I'm not very familiar with the Perl source.
If I have more time, I'll download the latest tarball and
check.

> > I suspect it may be related to the issue I
> > reported before (where Perl-spawned programs seemed to
> > be unable to use certain FDs).
> 
> One possible source of problems is if the same file whose name appears
> in the --error-output switch is already open by another program.

I ran m4 under gdb under Perl.  The fopen() succeeds and gives FD 4.
However, it seems FD 4 is off-limits in a Perl-spawned program:

  #! perl
  system "exec 4>blah"

when run this gives:

E:/Tmp/dj100000: redirection error: Bad file descriptor (EBADF)

The same goes for FD 7 and above, but FD's 3, 5 and 6 seem to work.
How can Perl mess up FD's that are available to the child program?

> What about m4: is that your own binary, or the one from SimTel?
The SimTel one has the same problems.