Bug #30011 for IO-Zlib: slurp read from IO::ZLib file handle fails if using Compress::Zlib

Mon Oct 15 10:13:16 2007 nigel.metheringham [...] Dev.intechnology.co.uk - Ticket created

Subject:

slurp read from IO::ZLib file handle fails if using Compress::Zlib

If you have an IO::Zlib read filehandle $fh, the code $string - do { local $/; <$fh> }; returns only the first line of the file if Compress::Zlib is being used and all of the file (as expected) if Compress::Zlib is not being used. I have attached a test case to this report. This is present in all versions back to 1.04 (not tested further).

Subject:

slurp.t

use Test::More tests => 7; BEGIN { use_ok( 'IO::Zlib' ); } $name="test.gz"; $contents = ""; foreach (1 .. 20) { $contents .= "line $_\n"; } ok($file = IO::Zlib->new($name, "wb"), 'open write'); ok($file->print($contents), 'print'); ok($file->close(), 'close write'); ok($file = IO::Zlib->new($name, "rb"), 'open read'); $uncomp = do {local $/; <$file>}; is ($uncomp, $contents, 'read content'); ok($file->close(), 'close read'); unlink($name);

Tue Oct 16 06:30:00 2007 nigel.metheringham [...] Dev.intechnology.co.uk - Correspondence added

Subject:	Re: [rt.cpan.org #30011] AutoReply: slurp read from IO::ZLib file handle fails if using Compress::Zlib
Date:	Tue, 16 Oct 2007 11:28:31 +0100
To:	bug-IO-Zlib [...] rt.cpan.org
From:	Nigel Metheringham <nigel.metheringham [...] Dev.intechnology.co.uk>

Better title would have been: IO::Zlib ignores $/ The Compress::Zlib man page has the following information:- $bytesread = $gz->gzreadline($line) ; Reads the next line from the compressed file into $line. Returns the number of bytes actually read. On EOF it returns 0 and in the case of an error, -1. It is legal to intermix calls to gzread and gzreadline. ! To maintain backward compatibility with version 1.x of this ! module gzreadline ignores the $/ variable - it always uses the ! string "\n" as the line delimiter. If you want to read a gzip file a line at a time and have it respect the $/ variable (or $INPUT_RECORD_SEPARATOR, or $RS when English is in use) see IO::Uncompress::Gunzip. So this is "intended" behaviour of Compress::Zlib. I suggest you add a note to the IO::Zlib documentation. Nigel. -- [ Nigel Metheringham Nigel.Metheringham@InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ]

Tue Nov 20 13:17:00 2007 tom [...] compton.nu - Correspondence added

On Tue Oct 16 06:30:00 2007, nigel.metheringham@Dev.intechnology.co.uk wrote: Show quoted text

> Better title would have been: > IO::Zlib ignores $/ > > The Compress::Zlib man page has the following information:- > > $bytesread = $gz->gzreadline($line) ; > > Reads the next line from the compressed file into $line. > > Returns the number of bytes actually read. On EOF it returns 0 > and in the case of an error, -1. > > It is legal to intermix calls to gzread and gzreadline. > > ! To maintain backward compatibility with version 1.x of this > ! module gzreadline ignores the $/ variable - it always uses the > ! string "\n" as the line delimiter. > > If you want to read a gzip file a line at a time and have it > respect the $/ variable (or $INPUT_RECORD_SEPARATOR, or $RS > when > English is in use) see IO::Uncompress::Gunzip. > > So this is "intended" behaviour of Compress::Zlib. > I suggest you add a note to the IO::Zlib documentation.

I think you're ascribing far too much to me if you think I intended one thing or the other - I can honestly say that I've never given it any thought. After reading this ticket, and some related bits of a p5p thread that I was CCed on I remain somewhat confused as to what I am supposed to be doing... My understanding is that, historically slurp was not supported by Compress::Zlib 1.x and hence by IO::Zlib. When external gzip support was added to IO::Zlib by Jarkko we wound up with the situtation where slurp did work, but only if external gzip mode was used. For a brief while Compress::Zlib 2.x did support it and hence IO::Zlib became consistent again and always did slurp. Compress::Zlib 2.x has now been changed to behave the same as 1.x hence making IO::Zlib inconsistent again. Short of explicitly documenting that it may or may not work (which seems bonkers) or asking for the change to Compress::Zlib 2.x to be reverted, I'm not clear how I can fix this...

Tue Nov 20 13:17:09 2007 The RT System itself - Status changed from 'new' to 'open'