Re: [MacPerl-Porters] [PATCH cfgperl 6212] MacOS regression suitemods

[Prymmer/Kahn <pvhp@best.com>]

On Sun, 11 Jun 2000, Chris Nandor wrote:

> At 12.47 -0700 2000.06.09, Peter Prymmer wrote:

> >
> >How do we get the C<require> to work without checking $^O eq 'MacOS'
> >and setting @INC?  Would you like an egg with your chicken or the
> >other way 'round?
> 
> You put paths.pl in the same directory as the file being called (copy it to
> each necessary directory).  Certainly a hack, but for the sake of testing
> ... not a horrible hack IMO.  As to doing some filespec conversion

That may be viable.  It is certainly the case that MacOS needs some
harness script I think.  The last time I tried the Unix harness it did
not work quite right and would at the very least need modification.
Adding a routine to spit out a paths.pl could certainly be added.

> ... not a horrible hack IMO.  As to doing some filespec conversion
> natively, heck, we already have some translation of / in paths (%INC and
> requires):
> 
>    require "Foo/Foo.pm";  # works in MacPerl now
> 
> I am personally not much in favor of this, though.  For years I had a main
> directory with "/" in the name.  You can change it to "%2F", but now what
> about all those routines that recognize each part of a filename as being
> only 31 characters long?  What about File::Spec and File::Basename parsing
> of these?  It seems like more confusion in some respects in exchange for
> less in others.
> 
> So anyway, I would like to know what would happen if I wrote this:
> 
>   use lib "Bourque:WP/DTP:lib:";
> 
> I've since changed the directory name to avoid such conflicts, but for many
> years, that's what it was, and I wouldn't be at all surprised if people had
> "HD:Programming/Coding:MacPerl:" directories.

You seem to be arguing against the auto conversion and I can appreciate
that (I would not have proposed my patch if I'd thought that auto
conversion was going to be done).  As it is I am not sure what form the
auto conversion will take but taking your example:

   use lib "Bourque:WP/DTP:lib:";

my guess is that it will first attempt to <use lib "Bourque:WP/DTP:lib:">
but if that does not work then fall back to <use lib "Bourque:WP:DTP:lib:">
then fail.

However, it gets considerably more tortuous when one considers a 
seemingly innocent open statement such as:

    open(HANDLE, "foo/bar/buz.dat");

note that it is under the 31 char limit, but that if  "foo/bar/buz.dat"
does not exist in the current working directory where do we start?  Because 
Mac HFS draws such a distinction between files and directories (I can make
a text file called "Trash" on my desktop for example), these are all
possible valid specs simultaneously:

    "foo:bar:buz.dat"
    "foo:bar/buz.dat"
    "foo/bar:buz.dat"
    ":foo:bar:buz.dat"
    ":foo:bar/buz.dat"
    ":foo/bar:buz.dat"

one might argue that the unix spec "foo/bar/buz.dat" was a relative
spec and as such the first of 3 these six are not to be considered,
but that still leaves 3 possible translated specs.  Perhaps the
first (namely ":foo:bar:buz.dat") ought to be tested first for opening,
but if it does not exist and if both ":foo:bar/buz.dat" and
":foo/bar:buz.dat" exist which should be opened and why?  In ASCII
sort order ":foo/bar:buz.dat" comes before ":foo:bar/buz.dat", but
that seems to be a bit of an arbitrary way to decide the matter.

Peter Prymmer



==== Want to unsubscribe from this list?
==== Send mail with body "unsubscribe" to macperl-porters-request@macperl.org