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

On Sat, Sep 15, 2001 at 05:46:11PM -0700, Peter Prymmer wrote:
> 
> 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.

Yup. The assumption being that if you're dialing up a specific
File::Spec::Foo, then you know what you're doing, and best of luck to
you.

>   % 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?

All File::Spec::* platforms but Unix happen to use the : as a token in
their grammar, so the non-portable path warning would come through on
any platform that didn't happen to use File::Spec::Unix. Unix should not
warn, since it thinks you want a directory named "C:" in the final path
(which would be relative to the cwd, in that case, a further oddness).

> 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?

Yes, you're passing a volume name to catfile() via the generic
File::Spec interface.  s/catfile/catpath/ and you'd be Ok.

Hmmm, new meme: a DCL shell on cygwin.  What "fun" ;-).

> The point I was trying to make was that absolute specs, as opposed to
> relative specs, can be intrinsically "unportable".

Even relative specs can be distinclty non-portable.  This spec on a
DOSish machine:

    "....\\foo"

is like

    "../../../foo"

(on Unix or DOS).  And things like what ( updir, updir, "foo" ) paths do
on different OSs when the cwd (or simulated cwd) is in or just below
root are another way relative paths are non-portable.

> 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.

Why use File::Spec to glue together non-portable paths?  It's a lot less
convenient than basic string manipulation, and the weasel clause I added
(don't warn if the call File::Spec::Foo->bar() instead of via
File::Spec->bar()) means that if you are writing platform-specific code,
then you should use the right File::Spec for that platform to dodge the
warnings.

The DCL trick you showed is nice, how likely is that in "the real world"
when running a script that is ostensibly portable (because it uses
File::Spec in the first place)?

> 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?

Don't want to stuff any tricks in there, just emit some helpful (I hope)
warnings to let you know you're using cat{dir,file} instead of
catpath().

> 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.

Hmmm?  You can still do all of the things you want to do, the warnings
just nudge you towards declaring your script's platform-specific nature
by using the appropriate File::Spec::Foo, or be (at least partially)
portable using the right method for the job (catpath()).

> My concern is that such a change would actually detract from the
> current ease of use of File::Spec.

Understood & appreciated.  Either we should make File::Spec for
cross-platform or platform-specific code (the former being it's raison
d'etre, however rough a start it had, the latter being a potential that
I see in it and occasionally use), or we should leave File::Spec alone
with the underspecified API and uneven implementation it currently
provides.  I prefer the former, but pragmatism may indicate the latter.

> was your intent to warn under cygwin with a leading M{\/\/[A-Z]\/}i ?
> What about UNC path names?

Not too concerned about covering every single base, but UNC and drive
letters on Win32 seem like low hanging fruit.  Passing a "/" in to
File::Spec::Unix->cat{file,dir}() (presumably what gets used on the OS X
and AIX platforms which you mentioned) would be a warning.  That latter
one is the most likely to cause the most warnings, I'd guess that a lot
of code lets directory separators sneak in to cat{file,dir} calls.

> 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,

I think this is where we differ, encouraging File::Spec to be used
non-portably is not a way to get to portable File::Spec uses.  In fact,
my biggest reservation about introducing warnings at this late date is
that I suspect there are a noticable number of non-portable uses of
File::Spec out there sleeping peacefully under the porch and I don't
want to wake them all up (see the original messages, IIRC, this meme
hasn't carried through to the last few messages).  That's the pragmatic
bit that could trump the warnings suggestion.

- Barrie