At 11:28 AM -0500 1/3/03, [EMAIL PROTECTED] wrote:
>OK here is the patch that could be applied to perl@18376
>to affect the change that I said I wanted.  With it
>applied (as well as the two test fixes that started this
>discussion thread) I see only these `mmk test` failures:
>
>t/run/switchi........................FAILED at test 2
>ext/Devel/Peek/Peek..................FAILED at test 21

I have fixes for those two that just need to be posted.

>lib/charnames........................FAILED at test 74

This one is a bit stranger and I haven't resolved it yet.

>lib/File/Find/t/find.................FAILED at test 1
>lib/File/Find/t/taint................FAILED at test 1
>lib/Net/hostent......................FAILED at test 5
>lib/Net/Ping/t/450_service...........FAILED at test 13
>Failed 7 test scripts out of 671, 98.96% okay.

I do not see any of those failures on OpenVMS Alpha 7.3-1, Compaq C
6.5, TCP/IP Services 5.3 ECO 1.  The File::Find tests can be thrown
off if there is a SYS logical name defined.  The Net stuff sometimes
depends on network services that may or may not be defined.

>The patch to vms/vms.c and vms/perlvms.pod appears as:

Looks good.

>So the questions I have are: 1. Does anyone besides me want to
>see this change in vmsperl?  2. If the answer to the previous
>question is "yes" then which interface is preferred?:

If it adds a capability we didn't have and doesn't break anything, go
for it.  I agree that adding a new switch is probably not a good
idea, and even though the triple quoting is a bit ugly, it's really
what anyone who knows how DCL works would expect.

-- 
________________________________________
Craig A. Berry
mailto:[EMAIL PROTECTED]

"... getting out of a sonnet is much more
 difficult than getting in."
                 Brad Leithauser

Reply via email to