Paul Marquess wrote:
From: John E. Malmberg [mailto:[EMAIL PROTECTED]
Paul Marquess wrote:

From: John E. Malmberg

<much snipping >



OK, I'll remove that code from my development copy.
This leaves the case where C::Zlib is built away from the core, which is
what the original code did

    $Inc = '-"I[.blib.lib]" -"I[.blib.arch]"'

Once someone gets around to building C::Zlib away from the core we can
revisit this.

I would not put in any VMS specific handling for $Inc. VMS should handle the UNIX case. It does for other modules.

The only reason for any VMS specific code that I can see is needed in this test is that the command to the child process has an argument that is enclosed in single quotes.

On VMS, enclosing an argument in single quotes causes the DCL shell to try to substitute it for a symbol of that name, and if there is no symbol, it replaces it as blank.

I do not know how I can easily detect this case inside the VMS specific Perl code that handles it with out breaking Perl scripts that are specifically written for VMS and depend on this behavior.

Tests 8,9,10,12,13 still fail for an unknown reason that I have not had
time to investigate.
Tests 10-13 all pass the STDIN filehandle to zlib. We discussed this earlier in the thread.
The only thing different about Tests 8 and 9 is that the test uses two
invocations of Perl with a "unix pipe" between them

   $Perl $Inc ${examples}/filtdef $file1 $file2 | $Perl $Inc
${examples}/filtinf 2>$stderr

Are there any issue with this on VMS? Perhaps there is an issue with passing
binary data through the pipe?

As discussed earlier, the error message is that the child perl process is dying when it tries to add the binary data to the pipe, before any data gets sent. I have not had time to investigate.

The pipe code in VMS Perl is complex, and I have not had time to investigate it. It is also adding \n to the data stream at times which does seem to cause some problems for other Perl scripts which are special casing for it.

VMS can handle binary data in a pipe.  I do not know if VMS Perl can though.

The main reason I am in blead-perl is that I have a number of fixes to the VMS filename handling code that I want to get merged in, but I need to get bead-perl stable enough to test them.

Currently in blead-perl, I have about 24 failures to chase down.

I have two data-corruption fixes pending in discussion on this list, and one of them does not appear to be VMS specific, the other is specific to a special case of VMS filename handling.

-John
[EMAIL PROTECTED]
Personal Opinion Only

Reply via email to