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 11:56:41 +0200
Message-ID: <CAEGKOHJKAAFPKOCLHDIIEKMCGAA.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)
In-reply-to: <2427-Wed15Aug2001121328+0300-eliz@is.elta.co.il>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
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

> It _is_ strange, but it's hard to analyze this unless you describe how
> does Perl implement the `system' feature.  Does it simply call the
> command via the `system' library function, or are there more steps in
> between?  For example, does it somehow stick the shell's name before
> the command?

I _think_ it's a plain system() wrapper - I'll check later today.

> > How can Perl prevent m4's error redirection from
> > working?
> 
> Redirection isn't involved here.  If you look into m4's sources
> (debug.c), you will see that it simply fopen's the file and assigns
> the resulting stream to a variable used to print the trace (which
> defaults to stderr).  This isn't redirection.

Then I'm pretty sure it's the Perl-hogs-FDs problem all over again.

> One possible source of problems is if the same file whose name appears
> in the --error-output switch is already open by another program.

It definitely isn't open (if that was it, using 2>foo instead of
--error-output should not have made a difference).

> If that doesn't give a clue, the only thing I can suggest is to
> replace "m4 --debug-flags=blah..."  with "gdb m4.exe", and then set a
> breakpoint in appropriate places and see what's going on.

Will do.  

> Btw, does the debug print-out appear on stdout, or does it disappear
> without a trace?

*poof*  The file is created, but nothing gets written to it.

> What about m4: is that your own binary, or the one from SimTel?

My own binary, but built from the SimTel sources.  Will try and see
if that makes a difference (though I doubt it).