[ John, I've combined responses to two of your messages into one here]
From: John E. Malmberg [mailto:[EMAIL PROTECTED]
> Paul Marquess wrote:
...
>
> > I see that the majority of the failures match those that Abe Timmerman
> > reported earlier today. Apart from running with bleed what else is
> different
> > between the two versions that could account for the extra failures you
> are
> > seeing? Is it anything to do with running the VMS C library in UNIX
> > emulation mode that you mentioned?
>
> I am not running the VMS C Library in UNIX mode.
Oops. Cut-n-paste error - I should have said "NOT running the VMS C library
in UNIX emulation mode".
> I am trying to get all
> unknown blead issues on VMS resolved so that I can start getting Perl to
> work when the C library is in that mode.
Sorry if I'm showing my ignorance of VMS, but does this mean that when you
run Perl on VMS you will/do have the choice of running the C library under
UNIX emulation mode or in VMS native mode?
Abe, does your copy of Perl run in UNIX emulation mode?
> It might have been one of my changes, or it might just be something that
> is different between our environments.
>
> See what happens below to the external.t test when I create a path
> logical name which has no meaning to VMS. Before it was silently
> skipped, and now it is a failure.
>
> And this is still with out the C library in UNIX mode.
>
> I will try to look at this some more later, I have blead perl and this
> module all built in debug so I should be able to find the real reason
> for these errors. Once I find the reason, it is likely that I could
> really use help for the correct fix.
If the problem is in my code I want to know about it and I'll certainly help
out. If it's someplace else I'll still try to help if I can.
> There are a number of places that the VMS specific code is failing
> silently because of a bug, and this is not detected because there is
> some fallback code that compensates. But there are also consequences to
> fixing those bugs as they expose others.
Ugh!
> >>lib/IO/Zlib/t/external.t
> >>1..0 # Skip: no /usr/bin/gzip
> >>
> >> If the GNV package is installed on VMS, then gzip is
> >> available at /bin/gzip. As I had nothing in /usr, I
> >> set up a logical name so that /usr/bin/gzip should
> >> find a gzip. This test still produced the same output.
> >>
> >> Also gzip may (or may not) be present anywhere on the
> >> system with a foreign command (shell alias) or the
> >> DCL$PATH search list used to find it.
>
> The test is verifying that '/usr/bin' is in $ENV{"PATH"}, an environment
> variable generally ignored on VMS. Easy to hack, but then the test
> fails later:
>
> lib/IO/Zlib/t/external.t
>
> ok 17
> >: non-translatable vms error code: 0x186D4
> %rms-f-syn, file specification syntax error
> PROJECT_ROOT:[PERL-BLEAD.t]test.gz;: no such file or directory
> ok 18
>
> not ok 21
> ok 22
> Can't call method "gzread" on an undefined value at ../lib/IO/Zlib.pm
> line 472.
> %RMS-E-FNF, file not found
Although it would be good to have these tests running on VMS, I'm not sure
if it is really necessary right now if you are going to be guaranteed to
have Compress::Zlib available in the core. The code it is exercising will
only kick in if Compress::Zlib is unavailable.
> >>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
> >
> > Not sure why this is failing for you but passing for Abe.
>
> I will have to investigate. There are enough Phase-of-Moon issues
> involved that it could be anything.
This code is writing to a file via a *FH style filehandle.
> ext/Compress/Zlib/t/05examples.t
> not ok 21 - exit status is 0
> # Failed test ([-.ext.compress.zlib.t]05examples.t at line 152)
> # got: '512'
> # expected: '0'
> not ok 22 - no stderr
> # Failed test ([-.ext.compress.zlib.t]05examples.t at line 153)
> # got: '71'
> # expected: '0'
> ok 23 - gzcat
> ok 24 - exit status is 0
> not ok 25 - content is ok
> # Failed test ([-.ext.compress.zlib.t]05examples.t at line 158)
> # got: '%RMS-E-FNF, file not found
> # '
> # expected: 'helloext/Compress/Zlib/t/06gzsetp.t
> <snip>
> # Looks like you failed 3 tests of 25.
Again this code is using a filehandle of the form *FH.
> >> Of this script, tests 31,48,52,56,60,68 are expected behavior
> >> on VMS when the C library is not in a UNIX emulation mode.
> >> I do not have blead Perl able to fully work in this mode yet.
>
> At the time that I wrote this, I had forgotten that readdir() seems to
> suppresses the trailing "." so this is an inconsistency.
>
> There is a problem with readdir() suppressing the trailing dot on a NULL
> file type in VMS mode. In some cases it is significant because if it is
> not present, VMS may add a default type when it tries to use the file.
>
> system("[]PERL") ! runs the file []Perl.exe
> system("[]PERL.") ! runs the file []Perl.
[ and this from the other thread]
> 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?
For now, at least, I've changed all the tests that hit glob to make sure
they have an extensions/file type.
> >>t/14gzopen......
> >>
> >># Failed test (t/14gzopen.t at line 421)
> >>
> >># Failed test (t/14gzopen.t at line 424)
> >>
> >># Failed test (t/14gzopen.t at line 425)
> >># gzerrno 0
> >># Looks like you failed 3 tests of 186.
> >
> >
> > OK, those failing tests are checking that gzopen can detect a non-
> writable
> > file. At the moment I'm creating one with this
> >
> > my $name = "test.gz" ;
> > ...
> > writeFile($name, "abc");
> > chmod 0, $name ;
> >
> > I imagine the "chmod 0, $name" is the non-portable part that I'm
> tripping
> > over.
>
> > Can you try changing line 419 of t/14gzopen.t to this please and report
> if
> > that makes any difference?
> >
> > chmod 0444, $name ;
>
> Unless a UNIX compatibility logical is set, the protection masks have
> different meanings on VMS. That feature is also only available on newer
> versions of VMS.
There are other instances of testing non-writable files in the test harness
that seem to be passing -- they use "chmod 0444, $name". I'll update my test
harness.
> >>t/22append......
> >>Cannot open abcde.out: file currently locked by another user
> >># Looks like you planned 490 tests but only ran 150.
> >># Looks like your test died just after 150.
> >>%SYSTEM-F-ABORT, abort
> >>dubious
> >> Test returned status 44 (wstat 1024, 0x400)
> >> (VMS status is 44)
> >>DIED. FAILED tests 151-490
> >> Failed 340/490 tests, 30.61% okay
> >
> >
> > I think this may be tripping over some debug code in the test harness.
> Under
> > VMS if you open a file for writing, can you then open it again for
> reading
> > whilst the write filehandle is still active? I think that is where this
> > error may be coming from
>
> VMS by default opens a file for exclusive access. There is a feature
> logical that can cause it to open a file for no locking at all. There
> is a VMS specific module that allows you do open a file and specify the
> sharing attributes.
>
> fcntl() file locking is not available in shipping versions of OpenVMS.
I've changed my test harness to remove the debug code.
> >>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.
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'll try to get an updated version of my module out tonight or tomorrow with
all of the fixes applied.
Paul
