Re: [PATCH] Test TestRequest pod
Christopher H. Laco wrote:
Christopher H. Laco wrote:
On that note, what else can I work on?
Apparently I'm a glutton for punishment.
Not sure, there are all kind of things in the ToDo file, but they all
mostly obscure.
I think all kind of refactoring would be great. One thing I wanted to do
for tests again vhosts, is to add this function next to module2path():
sub module2url {
my $module = shift;
my $scheme = shift || http;
Apache::TestRequest::module($module);
my $config = Apache::Test::config();
my $hostport = Apache::TestRequest::hostport($config);
my $path = Apache::TestRequest::module2path($module);
return $scheme://$hostport$path;
}
and then replace the long craft used a lot in the modperl tests, so now
one can write a simple:
my $module = Foo::bar;
{
my $path = Apache::TestRequest::module2path($module);
GET $path; # GET /Foo__bar
}
{
my $url = Apache::TestRequest::module2url($module);
GET $url; # GET http://localhost:8545/Foo__bar;
}
grep modperl-2.0/t for Apache::TestRequest::hostport to see what I'm
talking about.
OK, not that I've got a clean nmake/nmake test, I'm back on this. I'm
going to just start with t/modperl and go from there.
Since these patches will span A-T and modperl, should I send them
seperately to both lists, of send both sets to one list of the other?
-=Chris
Re: [PATCH] Test TestRequest pod
Since these patches will span A-T and modperl, should I send them seperately to both lists, of send both sets to one list of the other? if they include modperl and a-t send them to the modperl dev list. if only a-t post them here. thanks :) -- __ Stas BekmanJAm_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
Re: [PATCH] Test TestRequest pod
Stas Bekman wrote: Since these patches will span A-T and modperl, should I send them seperately to both lists, of send both sets to one list of the other? if they include modperl and a-t send them to the modperl dev list. if only a-t post them here. thanks :) Another opinion question amungst the A-TR and t/modperl changes: module2url vs. module2uri and my $url =vs. my $uri = -=Chris
Re: [PATCH] Test TestRequest pod
Christopher H. Laco wrote: OK, not that I've got a clean nmake/nmake test, I'm back on this. I'm going to just start with t/modperl and go from there. Since these patches will span A-T and modperl, should I send them seperately to both lists, of send both sets to one list of the other? -=Chris I've also noticed that some tests in t/modperl simply set their location my $location = /TestModperl__readline; while other tests use a full uri including the server/port (hostport, now module2url). Should all of them use the latter method for consistancy sake, or is there a reason for the madness? Thanks. -=Chris
Re: [PATCH] Test TestRequest pod
Christopher H. Laco wrote: Christopher H. Laco wrote: OK, not that I've got a clean nmake/nmake test, I'm back on this. I'm going to just start with t/modperl and go from there. Since these patches will span A-T and modperl, should I send them seperately to both lists, of send both sets to one list of the other? -=Chris I've also noticed that some tests in t/modperl simply set their location my $location = /TestModperl__readline; while other tests use a full uri including the server/port (hostport, now module2url). Should all of them use the latter method for consistancy sake, or is there a reason for the madness? Thanks. -=Chris Assuming we should always GET/POST/HEAD/UPLOAD to the full host:port/path and not just /path, what about making a more generic path2url($path) that uses config/hostport to create the full url. Then we can run module2url's path through that and use path2url for the test cases like t/modperl/readline.t that don't set A::TR::module? -=Chris
Re: [PATCH] Test TestRequest pod
Christopher H. Laco wrote: Stas Bekman wrote: Since these patches will span A-T and modperl, should I send them seperately to both lists, of send both sets to one list of the other? if they include modperl and a-t send them to the modperl dev list. if only a-t post them here. thanks :) Another opinion question amungst the A-TR and t/modperl changes: module2url vs. module2uri and my $url =vs. my $uri = Frankly I can never tell the difference (I know there is one). I normally use url... but whatever you like -- __ Stas BekmanJAm_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
Re: [PATCH] Test TestRequest pod
Christopher H. Laco wrote: Christopher H. Laco wrote: OK, not that I've got a clean nmake/nmake test, I'm back on this. I'm going to just start with t/modperl and go from there. Since these patches will span A-T and modperl, should I send them seperately to both lists, of send both sets to one list of the other? -=Chris I've also noticed that some tests in t/modperl simply set their location my $location = /TestModperl__readline; while other tests use a full uri including the server/port (hostport, now module2url). Should all of them use the latter method for consistancy sake, or is there a reason for the madness? If you use a relative path, it just goes to the default http://localhost:8529/. Not madness but for the sake of simplicity. Use relative path, unless you want to talk to a different port. -- __ Stas BekmanJAm_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
Re: [PATCH] Test TestRequest pod
Christopher H. Laco wrote: Christopher H. Laco wrote: Christopher H. Laco wrote: OK, not that I've got a clean nmake/nmake test, I'm back on this. I'm going to just start with t/modperl and go from there. Since these patches will span A-T and modperl, should I send them seperately to both lists, of send both sets to one list of the other? -=Chris I've also noticed that some tests in t/modperl simply set their location my $location = /TestModperl__readline; while other tests use a full uri including the server/port (hostport, now module2url). Should all of them use the latter method for consistancy sake, or is there a reason for the madness? Thanks. -=Chris Assuming we should always GET/POST/HEAD/UPLOAD to the full host:port/path and not just /path, what about making a more generic path2url($path) that uses config/hostport to create the full url. Then we can run module2url's path through that and use path2url for the test cases like t/modperl/readline.t that don't set A::TR::module? As explained in the other reply in this thread, there is no need to complicate things. The relative path works just fine. -- __ Stas BekmanJAm_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
Re: [PATCH] Test TestRequest pod
Stas Bekman wrote: Christopher H. Laco wrote: Christopher H. Laco wrote: Christopher H. Laco wrote: OK, not that I've got a clean nmake/nmake test, I'm back on this. I'm going to just start with t/modperl and go from there. Since these patches will span A-T and modperl, should I send them seperately to both lists, of send both sets to one list of the other? -=Chris I've also noticed that some tests in t/modperl simply set their location my $location = /TestModperl__readline; while other tests use a full uri including the server/port (hostport, now module2url). Should all of them use the latter method for consistancy sake, or is there a reason for the madness? Thanks. -=Chris Assuming we should always GET/POST/HEAD/UPLOAD to the full host:port/path and not just /path, what about making a more generic path2url($path) that uses config/hostport to create the full url. Then we can run module2url's path through that and use path2url for the test cases like t/modperl/readline.t that don't set A::TR::module? As explained in the other reply in this thread, there is no need to complicate things. The relative path works just fine. Understood. What led me to contimplating those thoughts was the fact that some tests use hostport, and config, and a custom path, but just don't set A::TR::module. If it weren't for that, those test could be slimmed as well. Baby steps, Chris. Baby steps. I should have a set of patches out for modperl/t and A::TR::module2url shortly after a few more distclean/nmake tests. -=Chris
Re: [PATCH] Test TestRequest pod
Christopher H. Laco wrote: Stas Bekman wrote: Christopher H. Laco wrote: Christopher H. Laco wrote: Christopher H. Laco wrote: OK, not that I've got a clean nmake/nmake test, I'm back on this. I'm going to just start with t/modperl and go from there. Since these patches will span A-T and modperl, should I send them seperately to both lists, of send both sets to one list of the other? -=Chris I've also noticed that some tests in t/modperl simply set their location my $location = /TestModperl__readline; while other tests use a full uri including the server/port (hostport, now module2url). Should all of them use the latter method for consistancy sake, or is there a reason for the madness? Thanks. -=Chris Assuming we should always GET/POST/HEAD/UPLOAD to the full host:port/path and not just /path, what about making a more generic path2url($path) that uses config/hostport to create the full url. Then we can run module2url's path through that and use path2url for the test cases like t/modperl/readline.t that don't set A::TR::module? As explained in the other reply in this thread, there is no need to complicate things. The relative path works just fine. Understood. What led me to contimplating those thoughts was the fact that some tests use hostport, and config, and a custom path, but just don't set A::TR::module. If it weren't for that, those test could be slimmed as well. That's when they use the default port. But that doesn't sound right, since they shouldn't need hostport/config and stuff. Where do you see such a test? Baby steps, Chris. Baby steps. :) I should have a set of patches out for modperl/t and A::TR::module2url shortly after a few more distclean/nmake tests. chris++ -- __ Stas BekmanJAm_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
Re: [PATCH] Test TestRequest pod
Understood. What led me to contimplating those thoughts was the fact that some tests use hostport, and config, and a custom path, but just don't set A::TR::module. If it weren't for that, those test could be slimmed as well. That's when they use the default port. But that doesn't sound right, since they shouldn't need hostport/config and stuff. Where do you see such a test? Now I have to go searching again. :-) modperl/t/hooks/trans.t - does module2path, config, then hostport. No module, but does custom urls towards the end. I know there's a couple more lurkers in there, but maybe I'll stumble across those during another round of module2path-ing. -=Chris
[PATCH] Apache::TestRequest::module2url
Here's the patch for Apache::TestRequest::module2url().
A set of patches to use it within the modperl tests is on it's way to
the dev list.
-=Chris
Index: lib/Apache/TestRequest.pm
===
--- lib/Apache/TestRequest.pm (revision 110069)
+++ lib/Apache/TestRequest.pm (working copy)
@@ -107,6 +107,23 @@
return $path;
}
+sub module2url {
+my $module = shift;
+my $opt = shift || {};
+my $scheme = $opt-{scheme} || 'http';
+my $path = $opt-{path} ||
+Apache::TestRequest::module2path($module);
+
+$path =~ s/^\///;
+
+Apache::TestRequest::module($module);
+
+my $config = Apache::Test::config();
+my $hostport = Apache::TestRequest::hostport($config);
+
+return $scheme://$hostport/$path;
+}
+
sub user_agent {
my $args = [EMAIL PROTECTED];
Re: [PATCH] Apache::TestRequest::module2url
Stas Bekman wrote: Christopher H. Laco wrote: Here's the patch for Apache::TestRequest::module2url(). A set of patches to use it within the modperl tests is on it's way to the dev list. Thanks Chris, committed with a few tweaks. Next it'd be nice to add a pod entries for this and module2path wrappers. As I have suggested earlier, if you have a patch that touches both modperl and a-t it's the best to send it together (even though svn's externals handling sucks and it won't show you 'svn diff' for the two at once, one needs to run those separately :( Oke dokie. I'll tackle the pod tomorrow. Thanks, -=Chris
Re: [PATCH] Test TestRequest pod
Christopher H. Laco wrote: Understood. What led me to contimplating those thoughts was the fact that some tests use hostport, and config, and a custom path, but just don't set A::TR::module. If it weren't for that, those test could be slimmed as well. That's when they use the default port. But that doesn't sound right, since they shouldn't need hostport/config and stuff. Where do you see such a test? Now I have to go searching again. :-) modperl/t/hooks/trans.t - does module2path, config, then hostport. No module, but does custom urls towards the end. You mean t/hooks/trans.t? sure it does: Apache::TestRequest::module($module); or are you talking about a different test? I know there's a couple more lurkers in there, but maybe I'll stumble across those during another round of module2path-ing. -=Chris -- __ Stas BekmanJAm_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
Re: [PATCH] Test TestRequest pod
Stas Bekman wrote: modperl/t/hooks/trans.t - does module2path, config, then hostport. No module, but does custom urls towards the end. You mean t/hooks/trans.t? sure it does: Apache::TestRequest::module($module); or are you talking about a different test? ANd so it does. On that note, I'm going to bed. :-/
Re: apxs calls on Win32
On Sun, 5 Dec 2004, Stas Bekman wrote:
Randy Kobes wrote:
If apxs is installed on Win32, it is usually specified as a
.bat file. In querying apxs in apxs() of Apache::TestConfig,
however, Win32 needs both the path to cmd.exe (for running a
.bat command) and to Perl (in order to run apxs.bat) in
order to get something from
$val = qx($apxs -q $q 2$devnull);
This diff:
If it's only win32 case then +1 but if other platforms may have the same
problem, may be it's better to blindly launder $ENV{PATH} like we do in a
few other places (in which case there will be no need for this change, as
the right paths will be there already, correct?)
That's right - what about the following, copied from
the open_cmd sub of Apache::Build (for Win32, this needs
to use the ';' as the directory separator within $ENV{PATH},
rather than ':'.
==
Index: lib/Apache/TestConfig.pm
===
--- lib/Apache/TestConfig.pm(revision 110064)
+++ lib/Apache/TestConfig.pm(working copy)
@@ -1043,7 +1043,8 @@
# Temporarily untaint PATH
(local $ENV{PATH}) = ( $ENV{PATH} =~ /(.*)/ );
# -T disallows relative directories in the PATH
-$ENV{PATH} = join ':', grep !/^\./, split /:/, $ENV{PATH};
+my $sep = WIN32 ? ';' : ':';
+$ENV{PATH} = join $sep, grep !/^\./, split /$sep/, $ENV{PATH};
# launder for -T
$cmd = $1 if $cmd =~ /(.*)/;
@@ -1657,7 +1658,12 @@
return unless $self-{APXS};
my $val;
unless (exists $self-{_apxs}{$q}) {
-local @ENV{ qw(PATH IFS CDPATH ENV BASH_ENV) };
+local @ENV{ qw(IFS CDPATH ENV BASH_ENV) };
+# Temporarily untaint PATH
+(local $ENV{PATH}) = ( $ENV{PATH} =~ /(.*)/ );
+# -T disallows relative directories in the PATH
+my $sep = WIN32 ? ';' : ':';
+$ENV{PATH} = join $sep, grep !/^\./, split /$sep/, $ENV{PATH};
my $devnull = devnull();
my $apxs = shell_ready($self-{APXS});
$val = qx($apxs -q $q 2$devnull);
=
--
best regards,
randy
Re: apxs calls on Win32
On Tue, 7 Dec 2004, Stas Bekman wrote:
Randy Kobes wrote:
[ ... ]
==
Index: lib/Apache/TestConfig.pm
===
--- lib/Apache/TestConfig.pm(revision 110064)
+++ lib/Apache/TestConfig.pm(working copy)
@@ -1043,7 +1043,8 @@
# Temporarily untaint PATH
(local $ENV{PATH}) = ( $ENV{PATH} =~ /(.*)/ );
# -T disallows relative directories in the PATH
-$ENV{PATH} = join ':', grep !/^\./, split /:/, $ENV{PATH};
+my $sep = WIN32 ? ';' : ':';
+$ENV{PATH} = join $sep, grep !/^\./, split /$sep/, $ENV{PATH};
# launder for -T
$cmd = $1 if $cmd =~ /(.*)/;
@@ -1657,7 +1658,12 @@
return unless $self-{APXS};
my $val;
unless (exists $self-{_apxs}{$q}) {
-local @ENV{ qw(PATH IFS CDPATH ENV BASH_ENV) };
+local @ENV{ qw(IFS CDPATH ENV BASH_ENV) };
+# Temporarily untaint PATH
+(local $ENV{PATH}) = ( $ENV{PATH} =~ /(.*)/ );
+# -T disallows relative directories in the PATH
+my $sep = WIN32 ? ';' : ':';
+$ENV{PATH} = join $sep, grep !/^\./, split /$sep/, $ENV{PATH};
my $devnull = devnull();
my $apxs = shell_ready($self-{APXS});
$val = qx($apxs -q $q 2$devnull);
As soon as you see dup like this, think refactoring :) e.g. add
untaint_path(), that does the work and call it:
local $ENV{PATH}) = untaint_path($ENV{PATH});
Otherwise +1.
And of course this wrapper should probably used in open_cmd too!
OK, I'll do that - thanks!
Also is there some File::Spec thingy that defines record
separator in paths?
I looked through there - there's not one specifically
defined. There are special cases for various platforms:
Mac = uses ',', but needs $ENV{Commands}, not $ENV{PATH}
OS2 = uses ';', but also translates '\' to '/'
VMS = uses a different $ENV variable
So some of these (eg, Mac and VMS) would require special
handling just to get at the equivalent of $ENV{PATH}.
Is leaving it just as is OK for the moment (using ';' for
WIN32, ':' otherwise), and if someone has problems with it,
we can fix it then?
Also, I haven't tried it yet, but just to make sure the
email messages go to the right place - can one do a commit
to Apache-Test from within modperl-2.0 svn (from within
the Apache-Test subdirectory)?
--
best regards,
randy
Re: apxs calls on Win32
Also is there some File::Spec thingy that defines record
separator in paths?
I looked through there - there's not one specifically
defined. There are special cases for various platforms:
Mac = uses ',', but needs $ENV{Commands}, not $ENV{PATH}
OS2 = uses ';', but also translates '\' to '/'
VMS = uses a different $ENV variable
So some of these (eg, Mac and VMS) would require special
handling just to get at the equivalent of $ENV{PATH}.
Thanks for the research, Randy.
Is leaving it just as is OK for the moment (using ';' for
WIN32, ':' otherwise), and if someone has problems with it,
we can fix it then?
+1
Also, I haven't tried it yet, but just to make sure the
email messages go to the right place - can one do a commit
to Apache-Test from within modperl-2.0 svn (from within
the Apache-Test subdirectory)?
I think you can diff/ci only if you first cd into A-T dir. so it'll go to
the right list anyway. So there is no way you can commit the two at once I
think.
--
__
Stas BekmanJAm_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
