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

[pvhp@forte.com (Peter Prymmer)]

Chris Nandor wrote Fri, 4 Jun 1999:

> 
> At 19.52 -0400 1999.06.02, Peter Prymmer wrote:
> >Chris Nandor wrote in response to me:
> >

[snippage]

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

Yes AFAI can tell only the dosish platforms would benefit, like I said
about VMS: you can have it unixy or vmsy but you cannot mix them.  Hence 
$PATHSEPCLASS would only be of use on dos, os/2, windows, et al.

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

OK, so barring Mac problems with file_name_is_absolute(), how does this
patch strike you?

--- perl5.005_03/ext/IO/lib/IO/File.pm.orig	Wed Jul 29 17:59:40 1998
+++ perl5.005_03/ext/IO/lib/IO/File.pm	Wed Jun  9 20:26:35 1999
@@ -109,6 +109,7 @@
 use Symbol;
 use SelectSaver;
 use IO::Seekable;
+use File::Spec;
 
 require Exporter;
 require DynaLoader;
@@ -158,7 +159,9 @@
 	    defined $perms or $perms = 0666;
 	    return sysopen($fh, $file, $mode, $perms);
 	}
-	$file = './' . $file if $file =~ m{\A[^\\/\w]};
+	if (! File::Spec->file_name_is_absolute($file)) {
+            $file = File::Spec->catfile(File::Spec->curdir(),$file);
+        }
 	$file = IO::Handle::_open_mode_string($mode) . " $file\0";
     }
     open($fh, $file);
End of Patch.

I just tested that on Tru64 Unix (formerly Digital Unix, formerly OSF/1)
and all 5.005_03 tests passed.

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

I just re-read the problem you mentioned here.  I'd advocate avoiding
an -e stat test.  What if you wanted to check a file spec before you'd ever 
opened it for the first time, it would not necessarily exist yet (e.g. you 
wanted a tempname() function that did not load all of POSIX).
Instead do things purely lexically, e.g.:

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

I think that is correct even for ::up_by_one specs - no?

I can think of one tiny problem: what happens to file path names when 
you delete the volume name, i.e. in the limit

    lim      chars:foo:bar -> :foo:bar ?
   chars->''

or does it become <weird_char_such_as_null>:foo:bar ?

OK I just ran `directory` in MPW and tried to delete all chars in the volume 
name, but Finder would not let me do it.  The last name would always pop 
back so I guess this is not a problem :-)

Peter Prymmer



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