Re: [MacPerl-Porters] Re: File::Spec catfile etc.

On Fri, 14 Sep 2001, Barrie Slaymaker wrote:

> On Thu, Sep 13, 2001 at 08:57:49PM -0400, Chris Nandor wrote:
> > So did we ever come to a consensus on this issue?  I think where we left it:
> >
> > 1. catfile/catdir should be relative by default
>
> Yup.
>
> > 2. if the first argument is something denoting a root-level item ('/',
> > 'HD:', 'C:')
>
> When on that platform.  This is so non-portable that I think we should
> emit warnings, so that code written on Win32, say, that calls
>
>     $path = "C:\foo" ;
>     $fullpath = File::Spec->catfile( $path, "bar" ) ;
>
> emits a warning about non-portable usage.  However, I'd prefer that
>
>     $fullpath = File::Spec::Win32->catfile( $path, "bar" ) ;
>
> not warn, though it's not a big deal to me.

Then what value has adding the warning to:

     $path = "C:\foo" ;
     $fullpath = File::Spec->catfile( $path, "bar" ) ;

added to File::Spec?  If I am on win32 and I want to concatenate names
into a valid win32 file spec I no longer can without specifying:

     $fullpath = File::Spec::Win32->catfile( $path, "bar" ) ;

Is it not the case that the former implies that I have at least given some
thought to portability.  Note that it would have been much easier for
me to specify:

     $path = "C:\\foo" ;
     $fullpath = "$path\\bar" ;

Rather than using the File::Spec lib module(s).

The problem with the "portability" goal is that on non rooted file systems
(basically most non-Unix) that there can be no agreeing on full path names
anyway.  Sure I might very well expect to see these on win32:

     A:\
     C:\
     D:\

And I might very well see these on VMS:

     _SATURN::DKA100:
     _SATURN::DKA200:
     _SATURN::DKA300:

but why would perl need to remind me that the two sets are different?  As
a Perl programmer trying to write $fullpath specs (rather than say
relative path specs) I ought to be well aware that such a construct is not
portable.  With such a task I might turn to branching on the $^O variable
myself (or betteer still: re-thinking the program design to avoid full
specs altogether).

> or an empty string (''), then
the behavior should be some sort > > of platform-specific absolute path
>
> This should probably warn too, since it's non-portable, especially on
> volume oriented machines, where MacOS has a documented fallback for the
> root, Win32 could reasonably use either "C:\" or the current selected
> volume for the root  (which is what "\" is).
>
> > 3. for real absolute paths rely on catpath
>
> Yes.
>
> The only thing that worries me about the warnings bit is that some apps
> that formerly worked will start whinging, but I think they were relying
> on undocumented and unsupported behavior and in some cases we're doing
> them a favor by nudging them towards portability. Of course, in other
> cases we're just annoying them, but hey.

I think that the annoyance of the warnings detracts from the desirablity
to even use File::Spec to begin with.  My worry is that folks will start
avoiding it rather than getting to know it.  E.g. look at the
non-portability of the installperl script.  It currently works only on
Unix, Windows, and VMS (perhaps other POSIXly oriented environs).  It
won't work on MacOS at all and ought to use the build
directorie's copy of File::Spec.

I suspect, although I have not attempted to code it, that adding the
various warnings will fill up File/Spec.pm and/or the various
lib/File/Spec/$osname.pm files with a lot of extra regular expession
parsing and whatnot that will slow File::Spec down.

> If folks agree to the warnings, than once the MacOS and VMS code, tests, and
> docs settle down, I'll patch in the warnings and do doc cleanup.
>
> Sound reasonable?

Count me as skeptical, but willing to look at a patch.

> - Barrie
>
> P.S. Just a note to disavow ownership of File::Spec. Contrary to
> published reports, I don't accept/deny patches to File::Spec nor control
> it's destiny.  I just help out with it, like everyone...

Thanks for the help you've given thus far.  Even pulling it out of
MakeMaker was a challenging task for which I am grateful.

Peter Prymmer