From: John E. Malmberg [mailto:[EMAIL PROTECTED]
> Paul Marquess wrote:
> > From: John E. Malmberg [mailto:[EMAIL PROTECTED]
...
>
> >
> >>>>ext/Compress/Zlib/t/04def.t fails on test 102 and dies.
> >>>>not ok 102 - create IO::Gzip
> >>>># Failed test ([-.ext.compress.zlib.t]04def.t at line 322)
> >>>>Can't call method "fileno" on an undefined value at
> >>>>[-.ext.compress.zlib.t]04def.t line 324.
> >>>># Looks like you planned 1781 tests but only ran 102.
> >>>># Looks like your test died just after 102.
> >>>>%SYSTEM-F-ABORT, abort
> >>>
> >
> > This code is writing to a file via a *FH style filehandle.
>
> I do not have access to the system i am running the tests on at the
> moment, but did look at this a bit last night. The *FH filehandle was
> opened, and then something tried
> an operation to set a variable named $x.
>
> That failed for a reason that I have not determined. I was stepping
> through the code in the debugger, and suddenly was in sub destroy.
I must be triggering object destruction too soon for some reason. If working
with the full test harness is too cumbersome, this should be the equivalent
of the test that is failing
use strict;
use warnings;
use blib;
use IO::Gzip;
my $name = "abc.def";
open FH, ">$name"
or die "Cannot open $name: $!\n";
my $x = new IO::Gzip *FH
or die "Cannot create IO::Gzip object\n";
...
>
> >
> >>On VMS, all filenames have a period to delimit where the name part ends
> >>and the extension (also known as file type). If there is a NULL type,
> >>then the period still is returned.
> >>
> >>There is another special rule about specifying filenames with a NULL
> >>type. If a utility gets a file with out the type specified, it will
> >>append a default type, unless the NULL type is explicitly specified by a
> >>trailing period.
> >>
> >>But this behavior could be considered a bug in the VMS code because it
> >>is leaving the trailing period in glob, but it is removing it with
> >>readdir() on Perl. Not consistent behavior.
> >
> >
> > So is the trailing period issue something that will be fixed at your
> end, or
> > do I need to rework my tests to always use filenames with
> extensions/file
> > type?
>
> Yes or no. It is a bit grey. And I am not sure how to fix it and keep
> everyone happy.
>
> I think that you may need to always use a non-null file type.
I'm sure can live with that.
> >>>>t/16top.........
> >>>>glob failed (can't start child: invalid argument) at /P5M/
> >>>>COMPRESS-ZLIB-2_000_01
> >>>>/blib/lib/Compress/Zlib/Common.pm line 232.
> >>>>legal or die??? at /P5M/COMPRESS-ZLIB-2_000_01/blib/lib/Compress/Zlib/
> >>>>Common.pm
> >>>>line 237.
> >>>
> >>>
> >>>That is tripping over file globbing. The test is failing when I try to
> >>>execute this
> >>>
> >>> glob "in[1234]"
> >>>
> >>>and there are 4 matching files "in1", "in2", "in3" and "in4".
> >>>
> >>>Hmm, just had a read at perlvms.pod -- is VMS complaining because
> >>
> >>"[1234]"
> >>
> >>>looks like a directory or does it not support '[1234]' as a wildcard
> >>>character class?
> >>
> >>Most likely. Currently in most places that Perl is trying to determine
> >>if a filename is in UNIX format or VMS, it is only looking for
> >>m{[]:<>;}. The caret character should also be added to that mix as that
> >>is used on escape extended characters.
> >>
> >>The other test that is used to determine if a file is UNIX is to see if
> >>it contains a '/' character.
> >>
> >>Also glob on VMS is done in C code, not by passing the glob through to
> >>the shell.
> >
> >
> > I realise that VMS perl is trying to steer a middle course and have glob
> > work both with Unix filenames and VMS native filenames, but the
> parameter to
> > glob isn't a filename - it's a cut down regular expression. I assume
> thought
> > with the "[]" characters you are faced with a major culture clash -- it
> > can't be both a VMS directory and a character class at the same time.
>
> Yep. With ODS-5 it is even worse. "/" is a legal character in a VMS
> format file specification.
>
> Some rules need to be documented and enforced on how path names are to
> be interpreted. If both UNIX and VMS path names are to be mixed, then
> some rule is needed to decide the ambiguous cases.
>
> The fun is doing it with out breaking any existing Perl scripts.
>
> > Assuming character classes are supported, is it possible to either make
> VMS
> > think that the glob is a Unix filename or to escape the [] characters so
> > that they will be used as character class delimiters?
> >
> > For example, if prefix the globs with "./" like this
> >
> > glob "./in[1234]"
> >
> > will it go into VMS mode or Unix mode?
>
> I do not know with out trying it, or code inspection. It depends on
> what particular check that the code is making. If it is checking for a
> "/" then it will go into UNIX mode.
Well the 2.000_03 release has used the "./" prefix for the tests that need
character classes.
> > I'll try to get an updated version of my module out tonight or tomorrow
> with
> > all of the fixes applied.
>
> Please let me know what files you change and where I should put them in
> blead because that is where I am set up to test them.
The only things you need to bother with are the test files. I'd just delete
all the files in bleed/ext/Compress/Zlib/t and copy all the files from the
"t" directory (with the exception of t/17isize.t) of 2.000_03 into
bleed/ext/Compress/Zlib/t.
> ZLIB is now the only test failing that I do not know a potential
> solution for, and what I want to do next is activate both the "case
> preserved" and "case sensitive" modes in vms.c.
I think before going much further with this we need to decide whether you
should continue with Compress::Zlib 1.x or 2.x. Which we go with is
dependant on what the purpose of your porting effort is.
If your intention is to keep up with bleed so that VMS is kept fully in sync
with future perl developments (like the eventual 1.10), I think sticking
with 2.x is probably the way to go. If so, it might then be better to get
2.x included in bleed soon, even though it is still a work in progress.
If, on the other hand, you just want a stable 5.8'ish perl for use in the
short term, 1.x might be a better bet. Version 1.x is very well established
and hasn't changed that much is years.
Paul
