t/tools/pbc_dump.t: Overly sensitive to how its path is spelled

[James E Keenan]

In the course of working on a branch yesterday and today, I noticed this 
anomalous behavior in t/tools/pbc_dump.t.  Let's call it with 'prove':

#####
$ prove  t/tools/pbc_dump.t
t/tools/pbc_dump.t .. ok
All tests successful.
Files=1, Tests=25,  8 wallclock secs ( 0.13 usr  0.04 sys +  2.21 cusr 
4.51 csys =  6.89 CPU)
Result: PASS
#####

Everything's fine.  Now, let's call it in a way which, in principle, 
ought to deliver exactly the same results:  Let's prepend './' to the 
file's name:

#####
[parrot] 514 $ prove  ./t/tools/pbc_dump.t
./t/tools/pbc_dump.t .. 1/25
#   Failed test 'pbc_dump basic sanity'
#   at ./t/tools/pbc_dump.t line 236.
#                   'HEADER => [
#       wordsize  = 4   (interpreter's wordsize/INTVAL = 4/4)
#       byteorder = 1   (interpreter's byteorder       = 1)
#       floattype = 0   (interpreter's NUMVAL_SIZE     = 8)
#       parrot-version 3.8.0, bytecode-version 11.0
#       UUID: type = 0, size = 0
#       no endianize, no opcode, no numval transform
#       dirformat = 1
# ]
# DIRECTORY => [ # offs 0x30(48) = op_count 144, itype 0, id 0, size 0, ...
#       # 3 segments
#       type 3  BYTECODE_./t/tools/pbc_dump.t.1.pir      offs 0x3c(0xf0) 
       op_count 28
#       type 2  CONSTANT_./t/tools/pbc_dump.t.1.pir      offs 
0x58(0x160)      op_count 56
#       type 4  BYTECODE_./t/tools/pbc_dump.t.1.pir_DB   offs 
0x90(0x240)      op_count 12
# ]
# BYTECODE_./t/tools/pbc_dump.t.1.pir => [ # offs 0x3c(60) = op_count 
28, itype 0, id 0, size 6, ...
#  0000:  00000000 00000000 0000002a 00000001 00000000 00000002
# ]
# CONSTANT_./t/tools/pbc_dump.t.1.pir => [
#     # 0:
#     [ 'PFC_STRING', {
#               FLAGS    => 0x8100 (is_string,COW)
#         ENCODING => ascii,
#         SIZE     => 26,
#         DATA     => "./t/tools/pbc_dump.t.1.pir"
#     } ],
#     # 1:
#     [ 'PFC_STRING', {
#               FLAGS    => 0x9100 (is_string,external,COW)
#         ENCODING => ascii,
#         SIZE     => 4,
#         DATA     => "main"
#     } ],
#     # 2:
#     [ 'PFC_STRING', {
#               FLAGS    => 0x9100 (is_string,external,COW)
#         ENCODING => null,
#         SIZE     => 0,
#         DATA     => ""
#     } ],
#     # 3:
#     [ 'PFC_STRING', {
#               FLAGS    => 0x9100 (is_string,external,COW)
#         ENCODING => ascii,
#         SIZE     => 6,
#         DATA     => "parrot"
#     } ],
#     # 0:
#     [ 'PFC_PMC', {
#               FLAGS    => 0x80200 (is_PMC,custom_mark)
#               class => FixedIntegerArray,
#               repr => '[  ]'
#     } ],
#     # 1:
#     [ 'PFC_PMC', {
#               FLAGS    => 0xc0200 (is_PMC,on_free_list,custom_mark)
#               class       => Sub,
#               start_offs  => 0,
#               end_offs    => 6,
#               name        => 'main',
#               subid       => 'main',
#               method      => '',
#               nsentry     => 'main',
#               namespace   => Null,
#               HLL_id      => 0,
#               n_regs_used => [ 1, 0, 0, 0 ],
#     } ],
# ],
# BYTECODE_./t/tools/pbc_dump.t.1.pir_DB => [ # offs 0x90(144) = 
op_count 12, itype 0, id 0, size 4, ...
#   mappings => [
#     #0
#     [
#         OFFSET => 0,
#         FILENAME => ./t/tools/pbc_dump.t.1.pir
#     ],
#   ]
# '
#     doesn't match '(?^:CONSTANT_t)'

#   Failed test 'pbc_dump basic sanity'
#   at ./t/tools/pbc_dump.t line 236.

... ######## Skipping two similar test failures ########

./t/tools/pbc_dump.t .. 23/25 # Looks like you failed 3 tests of 25.
./t/tools/pbc_dump.t .. Dubious, test returned 3 (wstat 768, 0x300)
Failed 3/25 subtests

Test Summary Report
-------------------
./t/tools/pbc_dump.t (Wstat: 768 Tests: 25 Failed: 3)
   Failed tests:  1-2, 5
   Non-zero exit status: 3
Files=1, Tests=25,  8 wallclock secs ( 0.14 usr  0.03 sys +  2.20 cusr 
4.51 csys =  6.88 CPU)
Result: FAIL
#####

I get the same results with:

   perl t/harness --gc-debug t/tools/pbc_dump.t

versus:
   perl t/harness --gc-debug .t/tools/pbc_dump.t

Can anyone explain why the test results are so sensitive to what should 
be an innocuous difference?

Thank you very much.
Jim Keenan