File::Spec on CPAN, directory seps, efficiency

Steven Knight wrote:
> 
> On Tue, 29 Feb 2000, Barrie Slaymaker wrote:
> 
> Actually, we could use it immediately.  Unfortunately, this issue is
> holding up getting our next release of Cons out the door.

Cool: I'm in the critical path :-).

Ok, I'll get it out soonest with a -beta in the name, then either
rename it or re-release it (if there are changes) when 5.6 comes out.

Is it better for Cons for you to point users at a specific, known-good 
version, or to say "get the latest version"?  Until 5.6 goes out, we
won't be able to say version number the next non-beta File::Spec will 
be at.

> Is your plan that whatever gets released with 5.6 will be 0.8, or
> would it work to freeze what's there as 0.8 and then go on to 0.9...?
> Just throwing out ideas.

Version numbers are cheap.  I just increment them every change and
let them land where they may.  There are no binary compatibility issues
in File::Spec that I know of so File::Spec doesn't need to get too concerned 
about multiple '.'ed version numbers.

My main concern is actually the name of the tarball: if it's beta code, 
the name needs to prevent CPAN.pm from trying to upgrade production 
systems to use beta code.  So FileSpec-0.8-beta.tar.gz, perhaps.

> I'm willing to help out in any way that's useful.

Thanks: testing on an older perl, and perhaps patching, are very useful, 
thanks.  Same for testing on non-unix platforms.  I'm a little worried
about the File::Spec::VMS tests, since, unlike most of the other platforms,
that does a lot of referring to the VMS environment to do things.

> I'll check it out.  The test suite you added looks quite full, actually;
> excellent work.

As with most test suites, there are plenty of missing vectors, especially 
for the non-unix platforms.  The more the merrier.  Like one for:

>             File::Spec->splitdir( "/a/b/c" );
> 
>         Yields:
> 
>             ( '', 'a', 'b', '', 'c', '' )
>
> That "Yields" line is incorrect.  Either the '' between the 'b' and 'c'
> does not belong there, or the line being split should be "/a/b//c".

Gack: thanks for the bug report.  I try to make sure the code examples
have corresponding test suite entries, but inevitably there's breakage.

I'm also not sure that the trailing '' should be there either, I'll have 
to look.

> (Ordinarily, I wouldn't carp about something like this, 

Uh, you should: mean documentation sucks.

> but this caused me headache when I was trying to learn File::Spec 

Sorry...

> One question:  If I have to splitpath()+splitdir() anyway, can I test
> for an absolute path name by looking at the first directory element,
> as follows:
> 
> This works on UNIX and NT, but I don't have access to other systems.

On Mac and on VMS an leading separator indicates a relative path:

":d:file" on a Mac and "[.d]file" under VMS is synonymouse with 
"./dir/file", I believe.

Does File::Spec impact performance significantly?  I've been nattering
on about a more efficient functional version, but haven't done any
work on it in a long time due to (perceived) lack of interest.

- Barrie

• File::Spec on CPAN, directory seps, efficiency by Barrie Slaymaker
• Re: File::Spec on CPAN, directory seps, efficiency by Randy J. Ray
• Re: File::Spec on CPAN, directory seps, efficiency by Barrie Slaymaker
• Re: File::Spec on CPAN, directory seps, efficiency by Steven Knight