On Sat, 11 Dec 2004, Stas Bekman wrote:
Right, to make it a good test we need to know what env var exist but wasn't passed. And since in t/directive/setupenv.t we can actually access %ENV which should be a complete copy of shell env, it's easier to make a more sensible test.
So for example iterate over SHELL, USER, OS and see what's set in real $ENV{} and then check that it's not in %env returned by the server.
Good idea - how about the following:
================================================================ Index: t/directive/setupenv.t =================================================================== --- t/directive/setupenv.t (revision 111576) +++ t/directive/setupenv.t (working copy) @@ -5,8 +5,15 @@ use Apache::TestRequest; use Apache::TestUtil;
-plan tests => 3; +use constant WIN32 => Apache::TestConfig::WIN32;
+# on Win32, some user environment variables, like HOME, may be passed +# through (via Apache?) if set, while system environment variables are not. + +my @vars = qw(SHELL USER OS); + +plan tests => 2 + @vars; + my $location = '/TestDirective__setupenv';
my $env = GET_BODY $location; @@ -23,4 +30,11 @@
ok t_cmp $env{REQUEST_URI}, $location, "testing REQUEST_URI";
-ok not exists $env{HOME}; +foreach my $var(@vars) { + if ($ENV{$var}) { + ok not exists $env{$var}; + } + else { + skip "\$ENV{$var} not set", 0; + } +}
Well, that's not exactly what I was suggesting. Now we get skip on unix, when we releally need only one variable.
Index: t/directive/setupenv.t =================================================================== --- t/directive/setupenv.t (revision 111669) +++ t/directive/setupenv.t (working copy) @@ -23,4 +23,24 @@
ok t_cmp $env{REQUEST_URI}, $location, "testing REQUEST_URI";-ok not exists $env{HOME};
+{
+ # on Win32, some user environment variables, like HOME, may be
+ # passed through (via Apache?) if set, while system environment
+ # variables are not. so try to find an existing shell variable
+ # (that is not passed by Apache) and use it in the test to make
+ # sure mod_perl doesn't see it
+
+ my $var;
+ for (qw(SHELL USER OS)) {
+ $var = $_, last if exists $ENV{$_};
+ }
+
+ if (defined $var) {
+ ok t_cmp $env{$var}, undef, "env var $var=$ENV{$var} is ".
+ "set in shell, but shouldn't be seen inside mod_perl";
+ }
+ else {
+ skip "couldn't find a suitable env var to test against", 0;
+ }
+
+}===================================================================
In testing this out on Win32, I found that whether or not an
environment variable gets passed thru is more complicated
than I initially believed. On Windows, at least with recent
flavours, there's "system" environment variables, and then
there's environment variables a user may set. The user
environment variables, if they're set, get passed thru
(that's why I was seeing $ENV{HOME}). However, "system"
environment variables, like OS used in the above test, don't
get passed through. I'm not quite sure of the distinction
between system and user environment variables - that'll
require a better understanding of the relevant Apache
sources, which I'll try.
Ideally we should have set some custom env var at the server startup shell and then check that it's not seen. I think Apache-Test sets some of those vars, but it's hard to rely that those won't change in the future.
I've tried to use APACHE_TEST_HOSTNAME but it actualy uses it.
In any case please see if the above works for you. In the worst case we will just either drop that subtest or make it specific to unix.
-- __________________________________________________________________ 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]
