Stas Bekman wrote:
Steve Hay wrote: [...]
This makes sense after reading
http://perl.apache.org/docs/2.0/user/config/config.html#C_modperl_
http://perl.apache.org/docs/2.0/user/config/config.html#C_perl_script_
and sure enough the various tests that fail, e.g.
apache\scanhdrs api\rflush modperl\post_utf8 modules\cgi
specify "SetHandler perl-script" in their .pm files, while the test above that succeeded (api\lookup_ui) specifies "SetHandler modperl" in its .pm file.
Not a single test that uses 'perl-script' passes?
Without trawling through all the tests trying each one individually under t/SMOKE and looking to see how it is run (perl-script/modperl) I couldn't say for sure. I just happened to spot that the few failing ones that I've been looking at were all perl-script and a working one was modperl.
It's easy to get the list of tests that use perl-script, since they specify that explicitly in their .pm:
% grep -Ilr 'perl-script' t | grep -v "t/conf"| grep "\.pm" | perl -p -e 's/.*?Test(.*?).pm/lc($1)/e'
api/r_subclass
api/rflush
apache/cgihandler
apache/scanhdrs
apache/scanhdrs2
error/push_handlers
modperl/endav
modperl/env
modperl/print_utf8
modperl/post_utf8
modperl/cookie
modules/cgiupload
modules/cgi
So it looks like rather than us having the redirection stuff oddly working for some tests and not for others, what we actually have is a case of it never working! The tests that work only do so because they use the "modperl" response handler which skips the tie()'ing of STDIN/STDOUT.
But you said that they did work from 'make test'/ t/TEST, for some reason they only fail when run from t/SMOKE. Is that correct? So it's some sort of condition that t/SMOKE creates, creating the grounds for this problem.
Yes, that's correct - "nmake test" runs the entire testsuite without error, "perl t/SMOKE" falls over on various tests.
Can you confirm that it fails on all the 'perl-script' tests?
Do you have the same issue if you run them as:
perl t/TEST testname
instead of using 'nmake'? If that's the case, it's not an issue with SMOKE.
I assumed it was something to do with the IPC::Run3 stuff in TestSmoke.pm that we've been playing with (specifically the fact that it introduces new redirections of its own), and I was under the impression that it is only t/SMOKE that uses this TestSmoke module. Is that not the case?
Yes. But Smoke does nothing else but starting t/TEST and feeding tests to it, execution-wise. Anything that fails with t/SMOKE should fail the same way with t/TEST.
My thinking was that maybe the redirections in TestSmoke clash with the redirections done by perl-script, but they're fine with the modperl handler because that doesn't do any redirections of its own.
I doubt so, since the problem comes from the server, which has no idea what the client does, and has a totally different process environment, so I fail to see how the client can affect it. Unless there is something special about win32.
__________________________________________________________________ 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]