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

On Sat, 15 Sep 2001, Barrie Slaymaker wrote:

> On Sat, Sep 15, 2001 at 09:01:04AM -0700, Peter Prymmer wrote:
> >
> > Then what value has adding the warning to:
> >
> >      $path = "C:\foo" ;
> >      $fullpath = File::Spec->catfile( $path, "bar" ) ;
>
> Here you're asking for portability.
>
> > 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" ) ;
>
> There you're telling us that you're manipulating Win32 paths.

I think that I understood the intent of the proposed distinction to be
made between C<File::Spec->catfile();> and
C<File::Spec::${Platform}->catfile();> calls.

> If you need to put volume names in, then catpath() is needed.
>
> > Is it not the case that the former implies that I have at least given some
> > thought to portability.
>
> Exactly.  The former example is blighted by the (mistyped)
>
>    $path = "C:\\foo" ;
>
> ; what I meant to show was that if $path contains a volume spec or a
> dirsep, then a warning should be delivered.

Let's ignore the mystype and consider this set of commands typed into a
shell:

  % su -
  passwd: secret
  # cd /
  # mkdir 'C:'
  # mkdir 'C:/foo'
  # touch C:/foo/bar
  # perl -MFile::Spec -e 'print File::Spec->catfile("C:","foo","bar")'

Should perl have warned in that case?  What OS was perl running on in that
previous example?  Did it look like unix?   Are you sure it wasn't a unix
shell ported to Windows?

Let's consider another example:

 $ create/directory DKA200:[FOO]
 $ create DKA200:[FOO]BAR.
   Hello from BAr
  ^Z
 $ define/translation=concealed C DKA200
 $ perl "-MFile::Spec" -e "print File::Spec->catfile('C:','foo','bar')"

Should perl have warned in this latter case?  If so why?  This example is
drawn from VMS where, given the above commands, from the native shell I
can now run the command:

 $ dir C:[FOO]BAR.

and not have it warn me about 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).
>
> Yup.
>
> > 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.
>
> File::Spec's primary goal is portability.  It'll never be 100%, but we
> can keep nudging it towards the asymtote.
>
> > 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:
> >
>
> See them where?  Passed in to catdir() and/or catfile()?  Or catpath()?

The point I was trying to make was that absolute specs, as opposed to
relative specs, can be intrinsically "unportable".  The need to warn may
be moot since the person using them probably already knows that they're
committing a non-portable act by using an absolute spec.

In the second example I gave above I smoothed around the non-portablility
between Windows and VMS use of 'C:' as a path component by using a VMS
logical name.  I did not see a need to have perl warn there since the DCL
shell on VMS would not complain about a spec such as C:[FOO]BAR. and the
CMD.EXE shell would not complain about C:\FOO\BAR  So why should perl
feel compelled to warn me away from attempting to make one platform look
like another?  Admittedly I used tricks outside of perl to make one look a
bit like the other, but can we stuff all such tricks into
File/Spec/Win32.pm and File/Spec/VMS.pm?

> > but why would perl need to remind me that the two sets are different?
>
> It's not reminding you that they're different; it's warning you when you
> use them in a context that is supposed to be portable.  If you're

But then we move File::Spec from being flexible and capable of handling
both portable and platform specific concatenation issues to one in which
the warnings now dictate which arguments we are allowed to pass in.  My
concern is that such a change would actually detract from the current ease
of use of File::Spec.

> writing a program on Win32, and a C: or "\\" or even "/" sneaks in,
> File::Spec can do you the favor of warning you that you've got some
> platform specific bits sneaking in.

So we would warn with a leading /[A-Z]:/ on Win32, but under Cygwin bash
a path such as:

    C:\perl\bin\perl.exe

Is expressed as:

   //c/perl/bin/perl.exe

was your intent to warn under cygwin with a leading M{\/\/[A-Z]\/}i ?
What about UNC path names?  Waht about extensions to POSIX that access
alternate file specs via a leading '//' (e.g. MachTen accessin the Mac OS
HFS, OS/390 USS accessing the MVS data set name space, etc.)

> > 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.
>
> There will definitely be a few extra m// ops.  Not sure how important
> they are, since actually using a path for anything goes out to the FS
> and is therefore likely to be so slow that a few extra m// ops won't be
> noticed.  In theory anyway.
>
> The whole idea is for File::Spec to help people use it portably; if you
> don't need portability, just hack the paths manually (as you point out)
> or use File::Spec::Foo directly.  If we think the warnings are too much
> "help", I'm not too worried about adding them.

I see what you want to achieve and laud the goal.  I think that
encouraging _any_ use of File::Spec may be a better way to come closer to
attaining the portability goal, even if it means not warning about things
that File::Spec could very well warn about.  As such it would mean
allowing easier use of File::Spec - even at the expense of having to apply
portabiltity patches to programs that do things like:

   $perl_exe = File::Spec->catfile('C:','perl','perl.exe');

Peter Prymmer