Re: [PATCH] Re: Some VMS errors in DBI trunk - dbi_vms_20100918.patch (1/1)

2010/9/19 Craig A. Berry <[email protected]>:
> In article <[email protected]>,
>  [email protected] (Tim Bunce) wrote:
>
>> On Thu, Sep 09, 2010 at 06:05:09PM -0500, Craig A. Berry wrote:
>> > In article <[email protected]>,
>> >  [email protected] ("Martin J. Evans") wrote:
>> >
>> > > I ran DBI trunk on VMS (perl, v5.8.1 built for VMS_AXP) just to check it
>> > > out.
>> > > There were a lot of failures.
>
>> > I'm pretty sure DBI passed all tests on VMS sometime in the last year or
>> > two, so hopefully there's nothing too fundamental wrong.  I see what I
>> > can find.
>>
>> Wonderful. Many thanks Craig!
>
> I've attached a patch that gets VMS into about the same shape as other
> platforms, which is to say about 4-5 test failures mostly related to
> the z*51_dbmfile.t tests as of trunk@14425.  (The count is approximate
> since things are a bit of a moving target right now -- every time I've
> updated in the past week or so I've gotten new test failures and/or
> merge conflicts with what I've been trying to fix.)
>
> Here's what's in the patch:
>
> 1.) On VMS, assignments to %ENV normally persist after Perl exits, so
> when setting something up for a test, they need to be torn down in an
> END block to prevent subsequent tests from getting unintended
> environment settings.
>
> 2.)  A couple of the fake modules used for testing depend on readdir()
> returning at least one directory when passed an empty directory (it
> doesn't seem to matter *what* directory as long as there is something).
>  While unixy platforms typically get away with this assumption by
> getting the dot and dot-dot directories, the standard explicitly says
> the presence of these must not be depended on (and they don't exist on
> VMS).  The path of least resistances was to make test_dir() in t/lib.pl
> create its own placeholder directory inside the temp directory it
> creates.
>
> 3.)  On VMS, the .dir extension is reserved for directories, so
> SDBM_File creates its dir files with the .sdbm_dir extension.  A
> VMS-specific adjustment to 51dbm_file.t was needed for this.
>
> 4.) On VMS, there is no such thing as a file with no extension.  A file
> with zero-length extension is, by default returned from readdir() with
> a trailing dot.  A couple of tweaks were needed in DBD::File to get rid
> of that dot.
>
>
> The things that still fail look like:
>
> t/zvxgp_50dbm_simple.t ..... ok
> Can't store item CODE(0x14284e0) at ../../lib/storable.pm (autosplit
> into [--.lib.auto.Storable]_freeze.al) line 339.
> DBD::Gofer::db selectall_arrayref failed: Cannot open
> disk$i64sys:[craig.dbi.test_output_60891]krueger.lck: no such file or
> director
> y (2) at /D0/CRAIG/DBI/blib/lib/DBD/File.pm line 690 at
> /D0/CRAIG/DBI/blib/lib/DBI/DBD/SqlEngine.pm line 793; DBD::DBM::st
> execute f
> ailed [for Statement "select * from Krueger"] at DBI::PurePerl
> DBI::st::execute line 118. at ./t/51dbm_file.t line 82
> Can't use an undefined value as an ARRAY reference at ./t/51dbm_file.t
> line 83.
> Compilation failed in require at t/zvxgp_51dbm_file.t line 6.
> # Tests were run but no plan was declared and done_testing() was not
> seen.
>
>
> whereas on Mac OS X they look like:
>
>
> t/zvxnp_51dbm_file.t ....... 1/? DBD::DBM::db selectall_arrayref failed:
> Cannot open /Users/craig/dbi/test_output_31349/freddy.lck:No such file
> or directory (2) at /Users/craig/dbi/blib/lib/DBD/File.pm line 690 at
> /Users/craig/dbi/blib/lib/DBI/DBD/SqlEngine.pm line 793
>  [for Statement "select * from Krueger"] at ./t/51dbm_file.t line 74
> Can't use an undefined value as an ARRAY reference at ./t/51dbm_file.t
> line 75.
> Compilation failed in require at t/zvxnp_51dbm_file.t line 6.
> # Tests were run but no plan was declared and done_testing() was not
> seen.
> t/zvxnp_51dbm_file.t ....... Dubious, test returned 2 (wstat 512, 0x200)
> All 5 subtests passed

I hope both are fixed in the current DBI trunk. I verified my changes from
yesterday on NetBSD and MacOS X within the common checkout and
from a bae directory containing spaces.

Would be great when you can prove it again.

Thanks,
Jens