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

[pvhp@forte.com (Peter Prymmer)]

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?

> Hm.  I wonder if it might be a good idea to add a $FILESEP variable or
> something to File::Spec?  Maybe even two:  $FILESEP and $FILESEPCLASS, the
> latter being used for regexes like this.
> 
>   $file = catfile(curdir, $file) if $file =~ m{\A[^$FILESEP\w]};
> 
> Just some early morning thoughts.

Good thoughts too.  Fortunately your example provides an illustration of
why the VMS folks may be reluctant to have a $FILESEP variable since
it does not boil down to a single char or group of chars for VMS native
syntax.  Let's say that I wanted to vmsify this spec:

      /usr/local/man/man1/foo.txt

that could become either:

     usr:[local.man.man1]foo.txt

or:

     usr:<local.man.man1>foo.txt

so while the VMS $PATHSEP would probably be '.' you also need to watch 
out for :[]<> characters as well - hence it is not simply a matter of 
tr#\/#$PATHSEP# (see e.g. below patch where I don't look for a period).
The other problem with using $PATHSEP in IO::File is that VMS can use
any of the above file specs - it is just mixing/:[them] that causes 
trouble.

Syntax sensitivity comments hold for Mac OS where you have to watch 
out for volume absolute specs:

     usr:local:man:man1:foo.txt

vs. relative path specs:

     :usr:local:man:man1:foo.txt

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

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

First the simple one (this ought to be OK on any UNIX???):

--- ./ext/IO/lib/IO/File.pm.orig	Sat Jan 23 16:56:03 1999
+++ ./ext/IO/lib/IO/File.pm	Wed Jun  2 16:11:01 1999
@@ -158,7 +158,7 @@
 	    defined $perms or $perms = 0666;
 	    return sysopen($fh, $file, $mode, $perms);
 	}
-	$file = './' . $file if $file =~ m{\A[^\\/\w]};
+	$file = './' . $file if $file =~ m{\A[^\\/:\[<\w]};
 	$file = IO::Handle::_open_mode_string($mode) . " $file\0";
     }
     open($fh, $file);
End of Patch.

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.

FWIW neither had any deleterious effect on `make test` with _57 
on Digital Unix 4.0D.

All tests successful.
u=0.583333  s=1.11667  cu=56.15  cs=24.9  scripts=209  tests=8925

Peter Prymmer


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