Mail Archives: djgpp-workers/2001/08/15/05:56:23
> 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).
- Raw text -