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