Paul Marquess wrote:
From: John E. Malmberg [mailto:[EMAIL PROTECTED]
The script 03examples.t is failing at test 1 because the includes seem
to be set wrong for VMS.
<snip - answered in previous discussion>
This gets the script passing up to test 10 which causes the subsequent
tests to fail.
Test 10 triggers the perl interface to the zlib function gzdopen. This is
one of the non-portable hot-spots in Compress::Zlib (and is reworked
completely in the next version of Compress::Zlib).
DB<5> x `$Perl $Inc ${examples}/gzstream <$file1 >$file2 2>$stderr`
The error captured in the file $stderr is:
EAGLE> type err.out
Cannot open stdout: invalid argument
%C-F-EINVAL, invalid argument
The value for stdout should have been the filename hello2.gz, and there
should be nothing illegal about that. I will need to chase that down
later, if someone else does not find the fix before this.
Unless VMS works completely differently to Unix-land, that isn't the case.
The code that is triggering the error is this:
In this case it does. The input and output redirections on the command
line are handled by VMS specific code in the Perl binary, not by the
shell. There are probably other significant differences.
my $gz = gzopen(\*STDOUT, "wb")
or die "Cannot open stdout: $gzerrno\n" ;
I'm passing the STDOUT filehandle into gzopen, not the "hello2.gz" filename.
That in turn calls this code in Zlib.pm (where $file is the STDOUT
filehandle)
IO::Handle::flush($file) ;
my $offset = tell($file) ;
gzdopen_(fileno($file), $mode, $offset) ;
The gzdopen_ call is where I interface to the zlib gzdopen 'C' function.
Does VMS allow this messing with the STDOUT filehandle?
I do not know. I will need to do more investigations to find out why it
is failing, what I will have to do is find the actual C code that is
being processed.
Also, VMS has many internal file structures. GZIP and TAR can
effectively only work on to classes of files, STREAM and BINARY. For
the other types, information that is stored in the file header is not
preserved in the compressed file or archive anywhere, and with out that
information, there is no way to restore most files.
The natural text file format of VMS is known as VFC, which has a byte
count at the beginning of each record. STDIN, STDERR, and STDOUT are
normally text files.
I can think of two ways that TAR/GZIP can handle all VMS file types.
Either add an extra made up file that has the file header information,
or encode the file header information in the stored filename. Of course
that means that what ever restores the file on VMS would have to know
what is going on.
So this will take some investigation on a VMS system to see what the
real problem is.
-John
[EMAIL PROTECTED]
Personal Opinion Only
