On Fri, 3 Oct 2003, Steve Hay wrote:That didn't make any difference :(
Randy Kobes wrote:[ .. ]
I won't be able to try this until tomorrow, but a thought I had was that, since passing in 'undef' for STDIN to run3 (so that the child inherits the parent's STDIN) helps in apparently getting rid of the errors for STDIN, it may be worth trying that for STDERR and STDOUT as well. That is, do the STDOUT and STDERR dups and redirections before calling run3, at least for the tests. It's not pretty, but it may help to nail down where the problem lies.
I hope I've misinterpreted your instructions here, because what I've just tried didn't work at all :-s
I applied the attached patch to the version of TestSmoke.pm that included your most recent patch. This leaves the "undef" for STDIN, and now changes STDOUT and STDERR to "undef" as well, having first redirected them to the $log scalar. (I had to look up Perl's open() manpage for that -- I didn't realise you could re-direct a filehandle to a scalar! The manpage advises closing the affected filehandles before attempting such re-direction, which is what I've done.)
I probably haven't done the right thing w.r.t. error handling -- I just wanted to see if it worked.
It didn't.
:(
Now when I run "perl t/SMOKE" I find that an Apache.exe is started, and that's all! The SMOKE program exits and leaves Apache.exe running, but didn't actually run any tests! There's nothing in the error_log (after the server startup messages) either.
Hopefully I've just done it all wrong, and it'll work fine when you try it!... :-)
- Steve
You tried essentially what I was thinking of ... The only thing I can think of changing at the moment is to use a different scalar ($log_stdout and $log_stderr) for capturing STDOUT and STDERR ...
I still worry that I've got something terribly wrong, though. Surely it should at least start running some tests? I was expecting it to either work, or else fail as before with the "Failed to dup STDOUT" error on certain (not-so-)random tests.
Does my patch work on Linux? If not then I have got it all wrong, and we're not still staring at a Win32 problem.
- Steve
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
