On Mon, 1 Dec 2003, Stas Bekman wrote:
> Randy Kobes wrote:
> [...]
> >>Yes, it's ugly and those of us coding on unix will never
> >>remember to do that, leaving you with the boring cleanup
> >>job. Therefore please think of extending Apache::TestXXX
> >>API to have this Win32::GetLongPathName part hidden
> >>within. Both join "/", .. and Win32::GetLongPathName can
> >>go inside. e.g. catfile_normalized() and
> >>caturl_normalized()? where any post-processings like
> >>Win32::GetLongPathName will come from the _normalized
> >>part? I'm not sure if the name selection is good. Does it
> >>sound good?
> >
> > Yes, that sounds much better - I just included the diff
> > as an indication of what needed to be done. How about
> > the following:
>
> > =========================================================
> > Index: Apache-Test/lib/Apache/TestUtil.pm
> > ===================================================================
> > RCS file: /home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestUtil.pm,v
> > retrieving revision 1.31
> > diff -u -r1.31 TestUtil.pm
> > --- Apache-Test/lib/Apache/TestUtil.pm 29 Apr 2003 08:04:04 -0000 1.31
> > +++ Apache-Test/lib/Apache/TestUtil.pm 1 Dec 2003 07:03:50 -0000
> > @@ -26,7 +26,8 @@
> > t_client_log_error_is_expected t_client_log_warn_is_expected
> > );
> >
> > [EMAIL PROTECTED] = qw(t_write_perl_script t_write_shell_script t_chown);
> > [EMAIL PROTECTED] = qw(t_write_perl_script t_write_shell_script t_chown
> > + catfile_normalized caturl_normalized);
>
> Right, but I don't quite like the names I've suggested, they are too long and
> if they go to Util, they probably need to follow the convention and be /^t_/.
> Do you have any suggestions? I'd prefer a short name
>
> t_makeurl, t_makepath
Those names sound good ... However, there already is a
makepath function in Apache::TestUtil, for (physically)
making a path. How about t_caturl and t_catpath?
> BTW, regarding Win32::GetLongPathName($f), shouldn't
> File::Spec be fixed to do the right thing regarding the
> short path? what about canonpath()?
In this context I'm not sure what the right thing is ...
If one passed in a short path name into File::Spec, then
for it to do a conversion to a long path name would probably
be incorrect. And similarly for passing in a long path
name and getting a short path name. I think the philosophy
of File::Spec is just to work with what's given, and leave
it to the user to do any conversions needed.
> > +sub catfile_normalized {
> > + my $f = catfile(@_);
>
> may be run through canonpath as well?
If I'm reading File::Spec correctly, canonpath is called
within catfile.
> > + return Apache::TestConfig::WIN32 ?
> > + Win32::GetLongPathName($f) : $f;
> > +}
> > +
> > +sub caturl_normalized {
> > + my $f = File::Spec::Unix->catfile(@_);
> > + return Apache::TestConfig::WIN32 ?
> > + Win32::GetLongPathName($f) : $f;
> > }
>
> I'd use an explicit: join '/', @_ here. It doesn't sound
> right to use File::Spec::Unix->catfile for constructing
> urls, even if it happens to do that,
Shouldn't one also do some cleanup and checks, like is done
in catpath:
sub t_catpath {
my $file = canonpath(pop @_);
return $file unless @_;
my $dir = catdir(@_);
$dir .= '/' unless substr($dir, -1) eq '/';
return $dir.$file;
}
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
