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
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

> 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.

- Raw text -