At 05:03 PM 5/28/2002 -0400, John Peacock wrote:
>Michael G Schwern wrote:
>>On Tue, May 28, 2002 at 03:21:13PM -0400, John Peacock wrote:
>>
>>>[-.lib.ExtUtils.t]Command.t
>>>not ok 10 - checking modify time stamp
>>>#     Failed test ([-.lib.extutils.t]command.t at line 104)
>>>#     '3600'
>>>#         <=
>>>#     '1'
>>># mtime == 1022620378, should be 1022616778
>>>
>>>[-.lib.File]stat.t
>>>not ok 18 - ... and must match normal stat
>>>#     Failed test ([-.lib.file]stat.t at line 79)
>>>#          got: '16777221 240561 33133 0 8388740 128  11455 1022615198
>>>1022615198 1022026973  '
>>>#     expected: '16777221 240561 33133 0 8388740 128  11455 1022611598
>>>1022611598 1022023373  '
>>
>>These indicate that the mtime is somehow going off by an hour between stats.
>>Network drive or some other funny filesystem?
>
>Nope, absolutely ordinary local filesystem.  Do I need to triple check to see if this 
>machine has been adjusted for DST properly???

Worth a try. This should tell you:

$ show logical sys$timezone*

>>>[-.lib.File.Spec.t]rel2abs2rel.t
>>>Can't pipe "[--.user.jpeacock.perlsrc.perl]perl.exe;1 rel2abs2rel187043.pl": no
>>>such file or directory at [-.lib.file.spec.t]rel2abs2rel.t line 43.
>>>not ok 4 - canonpath on abs executable
>>>#     Failed test ([-.lib.file.spec.t]rel2abs2rel.t at line 65)
>>>#          got: ''
>>>#     expected: 'ok
>>># '
>>
>>That's peculiar.  Is it the perl part that's gone wrong or that
>>rel2abs2rel187043.pl somehow doesn't exist (which shouldn't be possible).
>
>The .pl file exists, but it is apparent that calling system with an absolute path for 
>perl is not doing what you think it is doing.  I tend to think that calling perl with 
>an absolute path is what is not working, not the test file not existing (or being in 
>the wrong place).

You mean relative path, right?  I don't see any reason that shouldn't work:

$ show default
  D0:[CRAIG.TEST]
$ perl -e "system('[-.perl]perl.exe -v');"

This is perl, v5.7.3 built for VMS_AXP
(with 1 registered patch, see perl -V for more detail)
[snip]


I've also been testing on VMS_AXP V7.2-1 and have not seen any of these failures.

Reply via email to