Re: [MacPerl] _57's pod failures: workaround

[Chris Nandor <pudge@pobox.com>]

At 19.52 -0400 1999.06.02, Peter Prymmer wrote:
>Chris Nandor wrote in response to me:
>
>> At 0.42 -0400 1999.06.02, Peter Prymmer wrote:
>> >Here is a workaround for the pod test suite failures
>> >that does away with a tiny UNIXism in FileHandle->new()
>> >which is implemented via IO::File::open():
>
>[snip]
>
>> What about using File::Spec, since it is now included with perl?
>>
>>   $file = catfile(curdir, $file) if $file =~ m{\A[^\\/\w]};
>
>This does look nice, but I've got a couple of other solutions
>down below.  While I have not benchmarked them I suspect either one would
>be quicker than resorting to File::Spec.  Does either look OK to you?


>obviously $PATHSEP eq ':' on MacOS but conversion is not necessarily a
>simple matter of tr/// or s///.  The potential for abuse of such constructs
>as well as the general principle of avoiding namespace bloat are further
>arguments against it (e.g. the name $PATHSEP is probably already in use
>in a lot of X-platform perl code I'd guess).  I guess I am not opposed
>to having a $PATHSEP or a $PATHSEPCLASS variable, but I think the
>advantage is
>small in the presence of proper subs such as File::Spec::catfile() and
>catdir().  (er, BTW how would you propose that $PATHSEPCLASS be used?).

The idea is that if there were more than one path separator possible, as in
Win32.  $PATHSEP = '/'; $PATHSEPCLASS = '/\\';  m/[$PATHSEPCLASS]/;  or
something.  Just a thought.  I think I agree it is not a Good Idea, because
it assumes that path separators work similarly everywhere, which they don't.

>I suspect that the following patches may need to be modified further to
>accomodate Acorn RiscOS - but how do they look for VMS && Macs?
>(assume the IO::File that comes with perl 5.005_57).

Right, and that's the problem with not using File::Spec.  You might miss
some other platform.


>Next the one that is a bit more complicated but goes further to isolate
>the modification to VMS and Mac OS:
>
>--- ./ext/IO/lib/IO/File.pm.orig	Sat Jan 23 16:56:03 1999
>+++ ./ext/IO/lib/IO/File.pm	Wed Jun  2 11:50:25 1999
>@@ -158,7 +158,11 @@
> 	    defined $perms or $perms = 0666;
> 	    return sysopen($fh, $file, $mode, $perms);
> 	}
>-	$file = './' . $file if $file =~ m{\A[^\\/\w]};
>+	if ($file =~ m{\A([^\\/\w])}) {
>+	    $file = './' unless
>+	        (($^O eq 'VMS' && ($1 eq '[' || $1 eq '<')) ||
>+                 ($^O eq 'MacOS'));
>+	}
> 	$file = IO::Handle::_open_mode_string($mode) . " $file\0";
>     }
>     open($fh, $file);
>End of Patch.

This is a tough one.  The filename should begin with ':' if it is a
relative file spec on Mac OS.  But I cannot think of a reliable way using
File::Spec to do this.  I wonder if File::Spec::Mac::file_name_is_absolute
should be changed?

sub file_name_is_absolute {
    my($self,$file) = @_;
        if ($file =~ /:/) {
                return ($file !~ m/^:/);
        } else {
                return (! -e ":$file");
    }
}

It checks for the existence of a file in the relative path, and returns
absolute if it isn't there.  Maybe instead it could check do:

  return -e ($file =~ /^([^:]+:)/)[0];

Then it just says "yes, there is a volume with that name".  I dunno.  I
guess we could just say, "hey dummy, pass your filenames to IO::File with
leading semicolons to disambiguate, we can't do all the thinking for you!"
That's basically what Paul's docs for File::Spec::Mac say.

--
Chris Nandor          mailto:pudge@pobox.com         http://pudge.net/
%PGPKey = ('B76E72AD', [1024, '0824090B CE73CA10  1FF77F13 8180B6B6'])

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