Randy Kobes wrote:
[...]
I've attached a patch (for Steve's benefit, as it's Win32
specific) which, first of all, uses Win32::Process (to
rule out problems coming from IPC::Run3), and which defines
two functions:
  run_command - uses system() to run a command, and
                returns a flag indicating success;
  run_command_dup - uses Win32::Process to run a command,
                    capturing the STDOUT and STDERR and
                    then returning the text.

- if one uses run_command_dup to start/stop the server and
run the tests, then the error with failing to dup STDOUT
results, for those tests that use perl-script.
- if one uses run_command_dup to start/stop the server, but
uses run_command to run the tests, then the same error
results.
- if one uses run_command to start/stop the server and run
the tests, then all tests pass.

What about the 4th option:


- if one uses run_command to start/stop the server and
uses run_command_dup to run the tests, ...


That works! So the problem seems to be in starting the
server with a dup/redirect of STDOUT/STDERR; if one does
it with just a system call:
   my @args = split ' ', $start_command;
   system(@args);
then it seems OK to do the dup/redirect when running
the tests (I tested this with Win32::Process, but
I imagine the same thing would hold for IPC::Run3).

Like you mentioned earlier, though, Stas, there doesn't
seem to be any reason why doing something like this
on the client side would affect the server side. Might
there be though in starting the server?

Now, that makes much more sense, Randy. Looks like we are making a progress on this. Indeed as you said doing 't/TEST -run testname' doesn't affect the server side. But the way you start the server does.


I suppose this has something to do with the win32 implementation of the server startup. If the server start with stdout redirected, it's not available for the server at all. You should be able then to reproduce this outside Apache-Test, just doing:

httpd > /dev/null &

and then trying to run requests on it, should reproduce the problem. If you can, then in my opinion it's a bug in httpd, which meanwhile we certainly can workaround. Instead of parsing the output of startup, we could check the return status of the command and thus. though we will end up with startup noise which is not nice at all.

Also I'm bit lost in all the redirect attempts that you have tried. Have you tried doing this in smoke:

dup STDOUT
t/TEST -start | # redirected so we can parse it
restore STDOUT
close the dupped fh
t/TEST -run test

also isn't the third option exactly what we have now with
IPC::Run? (i.e.  using system everywhere?)


The system() call I used was just that, with no STD
redirections.

very good!



__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to