From: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
To: "DJGPP-Workers" <djgpp-workers AT delorie DOT com>
Subject: Very strange behaviour in our Perl port (redirection issue?)
Date: Tue, 14 Aug 2001 22:08:40 +0200
Message-ID: <CAEGKOHJKAAFPKOCLHDIMEKACGAA.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
Reply-To: djgpp-workers AT delorie DOT com

I just discovered the cause of a major failure in the
current CVS autoconf.  Autoconf now uses a perl script
(autom4te) to do most of the work.  It runs m4, parses
the output, etc.  A major component of autoconf is its
trace facility.
Autom4te runs m4 like this:

  system "m4 --debug-flags=blah " .
         "--error-output=foo xyzzy >output"

For some strange reason, this fails (the file specified
in --error-output is always empty), even though running
exactly the same command using bash, or through system()
in a C program, DOES work (filling up the output file with
the traces autom4te needs to do its job).
It was easy enough to work around this (by using
redirection of stderr (2>blah) instead of m4's
--error-output option), but this all seems VERY strange.
How can Perl prevent m4's error redirection from
working?  I suspect it may be related to the issue I
reported before (where Perl-spawned programs seemed to
be unable to use certain FDs), but I'm hoping someone
can point me to likely suspects (as this seems to be a
very big problem).

For the record, I tried this with both my local,
self-made port of perl 5.6.0 and the official 5.6.1
port, with the same results.