Skip Menu |
 

This queue is for tickets about the IO-stringy CPAN distribution.

Report information
The Basics
Id: 66186
Status: open
Priority: 0/
Queue: IO-stringy

People
Owner: dfs+pause [...] roaringpenguin.com
Requestors: user42 [...] zip.com.au
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: IO::InnerFile readline() in list context
Date: Sat, 26 Feb 2011 10:11:11 +1100
To: bug-IO-stringy [...] rt.cpan.org
From: Kevin Ryde <user42 [...] zip.com.au>
Download (untitled) / with headers
text/plain 641b
In IO::InnerFile 2.110 with recent debian perl 5.10.1 a readline() in list context only returns one line, where I believe it should return all remaining lines of the file. foo.pl below prints the first line of /etc/passwd, where I believe it should print them all. Printing them all is what you get for instance from changing the readline <$inner> to <$outer>. Something like what IO::ScalarArray does would seem likely, sub READLINE { wantarray ? shift->getlines(@_) : shift->getline(@_) } with a rearrangement so READLINE calls getline instead of the other way around, and adding a getlines perhaps like IO::ScalarArray also has.
Download foo.pl
text/x-perl 222b
#!/usr/bin/perl -w use strict; use IO::File; use IO::InnerFile; my $outer = IO::File->new('</etc/passwd') || die; my $inner = IO::InnerFile->new($outer, 5, -s $outer) || die; my @lines = <$inner>; print @lines; exit 0;
Subject: Re: [rt.cpan.org #66186] IO::InnerFile readline() in list context
Date: Sat, 26 Feb 2011 10:59:32 -0500
To: bug-IO-stringy [...] rt.cpan.org
From: "David F. Skoll" <dfs [...] roaringpenguin.com>
Download (untitled) / with headers
text/plain 843b
On Fri, 25 Feb 2011 18:11:27 -0500 "Kevin Ryde via RT" <bug-IO-stringy@rt.cpan.org> wrote: Show quoted text
> In IO::InnerFile 2.110 with recent debian perl 5.10.1 a readline() in > list context only returns one line, where I believe it should return > all remaining lines of the file.
Hmm... I think it should return only one line, similar to what IO::Handle's getline() method does. I think the real bug is in IO::ScalarArray which should only return one line in array context. Anyway, I agree that it's inconsistent. At this point, I'm not too enthusiastic about making a new IO::Stringy release. With modern Perl's in-memory file I/O, I think IO::Stringy should simply disappear. We've spent a lot of effort to make MIME::tools no longer require IO::Stringy and I'd rather see other module authors remove dependency on IO::Stringy. Regards, David.
Subject: Re: [rt.cpan.org #66186] IO::InnerFile readline() in list context
Date: Wed, 02 Mar 2011 09:15:48 +1100
To: bug-IO-stringy [...] rt.cpan.org
From: Kevin Ryde <user42 [...] zip.com.au>
Download (untitled) / with headers
text/plain 1.5k
"David F. Skoll via RT" <bug-IO-stringy@rt.cpan.org> writes: Show quoted text
> > IO::ScalarArray which should only return one line in array context.
I think IO::ScalarArray is correct as it stands, and behaves as per IO::File, per ordinary handles, and per other tied handle modules (eg. IO::Uncompress::Base, though its gotos are not subclass friendly). Perhaps confusion in a couple of modules (I've got doubts about File::ReadBackwards ...) has arisen from the perltie docs which read a bit like READLINE returns one line, but which is not so, it should do all the various nonsense perlfunc says about readline() -- all lines in array context, slurp mode if $/ undef, etc etc. A bit of wording I proposed was accepted the other day, http://perl5.git.perl.org/perl.git/blobdiff/662ccb34c4d4ba5f4c287f08b854fc020ea25b20..2207fa4e5a04c326c157fe8acb453ee4b447205a:/pod/perltie.pod Show quoted text
> We've spent a lot of effort to make MIME::tools no longer require IO::Stringy > and I'd rather see other module authors remove dependency on IO::Stringy.
Oh, well, it does no harm to exist :-), and anyone using it presumably likes it, or doesn't yet want to do work to change. The docs of IO::Scalar could cross reference open \$str or whatever that the new feature is, for those using new enough perl to have that. -- At Sydney airport Australian passport holders may be asked to verify their citizenship by singing the national anthem. It's a trick. Anyone who knows more than the first two lines is an imposter. If you get to "girt by sea" and know what that means then expect to go to Villawood.
Subject: Re: [rt.cpan.org #66186] IO::InnerFile readline() in list context
Date: Wed, 2 Mar 2011 11:09:58 -0500
To: bug-IO-stringy [...] rt.cpan.org
From: "David F. Skoll" <dfs [...] roaringpenguin.com>
Download (untitled) / with headers
text/plain 280b
Hi, Kevin, Show quoted text
> I think IO::ScalarArray is correct as it stands, and behaves as per > IO::File, per ordinary handles, and per other tied handle modules > (eg. IO::Uncompress::Base, though its gotos are not subclass > friendly).
OK; please try the attached patch. Regards, David.
Download IO-Stringy.diff.gz
application/x-gzip 1k

Message body not shown because it is not plain text.

Subject: Re: [rt.cpan.org #66186] IO::InnerFile readline() in list context
Date: Fri, 11 Mar 2011 10:02:22 +1100
To: bug-IO-stringy [...] rt.cpan.org
From: Kevin Ryde <user42 [...] zip.com.au>
Download (untitled) / with headers
text/plain 668b
"David F. Skoll via RT" <bug-IO-stringy@rt.cpan.org> writes: Show quoted text
> > OK; please try the attached patch.
Almost, but I think getline() should not depend on wantarray, instead always return one line (per IO::Handle). I would make readline() call getline() or getlines() according to wantarray, with getline() being the _readline_helper() bit, and getlines() being the while(defined(...)) loop now in READLINE(). The readline() method and READLINE() tie will be the same no doubt, one calling the other or aliasing. Dunno which calling which way around is better. Perhaps the code in readline() and making READLINE() call to it might be slightly more subclass friendly.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.