Date: Wed, 15 Aug 2001 12:13:29 +0300
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
Message-Id: <2427-Wed15Aug2001121328+0300-eliz@is.elta.co.il>
X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.9
CC: djgpp-workers AT delorie DOT com
In-reply-to: <CAEGKOHJKAAFPKOCLHDIMEKACGAA.tim.van.holder@pandora.be>
Subject: Re: Very strange behaviour in our Perl port (redirection issue?)
References:  <CAEGKOHJKAAFPKOCLHDIMEKACGAA DOT tim DOT van DOT holder AT pandora DOT be>
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

> From: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
> Date: Tue, 14 Aug 2001 22:08:40 +0200
> 
>   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.

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?

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

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

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

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.

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

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

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