Randy Kobes wrote:
In the effort to remove some of the Win32 noise, I was thinking that we can write a generic function which gets a path as an argument and figures out internally if it needs to keep the argument as passed or mangle it. So it'll do something like:
my $cwd = Apache::TestUtil::path(cwd);
probably need a more intuitive name for this function.
That'd be nice - a version that does this appears below. I named it win32_long_path - it'll just return what was passed into it if not on Win32.
But my idea was to eliminate any os-specific words win32. I think it should just be long_path... Think of it as File::Spec function.
OK, I'll do that. I put in the win32_ to indicate that it'll do something for Win32, and otherwise just return what was passed in.
I'm still not quite happy about the naming of the function, what exactly GetLongPathName($file) does? can this be done using some File::Spec function?
I haven't found an equivalent one in File::Spec ... The problem here is that cwd (or any file/directory name) on Win32 has two representations - a long path name (that can include spaces) and a short path name, limited to 6 characters (this is a holdout from early days), plus 3 if an extension is present. Here we want to match cwd to /Apache-Test/, but cwd may return the short path name (eg, Apache~1.0), depending on if, for example, you have different Apache-Test* directories at the same level. So GetLongPathName can be used to get the full long path name.
The thing with naming it, eg, just long_path, is that Unix users (the majority) wouldn't know what it does.
Thanks Randy. Call it 'expand_path' and add the above explanation to that function? for unix it won't do anything, since there is nothing to expand, but for win32 it will expand the shrinkwrapped name.
+ if (-e $candidate) { + $sys_config = $candidate; + last; + } + } + if ($sys_config) { + eval {require $sys_config}; + return $sys_config if (not $@ and IN_APACHE_TEST); + $sys_config = undef if $@; + }
Hmm, I thought we agreed that eval {require $sys_config} will always succeed, since that file is always available. so this code should be needed:
+ die 'Could not find a suitable Apache::TestConfigData' + unless defined CONFIG_DATA;
I was thinking here if someone, after installation, had mis-edited Apache::TestConfigData, either the system one or one found in some path in @INC being added thru, eg, use lib). But this might be overkill - not worrying about this at this time will simplify things here.
Yup, just die then...
I was also thinking about the problem of $ENV{HOME} not
being available in mod_perl. As Apache::TestConfigData is
being loaded in order to configure things, shouldn't
this not be a problem, because at this point one isn't
yet in a mod_perl environment?
It can be used at run time just as well, I think we do that in several places in the test suite. However for now we can cheat, by documenting:
add:
PerlPassEnv HOME
to httpd.conf if you want to read ~/.apache-test/ config from within a running mod_perl server. Another possible alternative is to use: getpwent() to ask the os for the home dir instead of relying on $ENV{HOME}. Does this work under 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
