On Tue, Mar 29, 2005 at 08:37:02PM -0700, Luke Palmer wrote:
: Stevan Little writes:
: >
: > On Mar 29, 2005, at 8:38 AM, Luke Palmer wrote:
: > >Hmm... I believe that the behavior in this case is undefined. It sure
: > >would be nice if it worked, but you see:
: > >
: > > for =$fh -> $line { ... }
: > >
: > >Evaluates `=$fh` in list context. In an eager world, this eats up the
: > >whole file in one go. In the ideal lazy world, it reads one line at a
: > >time (which would allow this example to work... I think). And perhaps
: > >that's how we need to define it.
: >
: > Personally I like the idea of this being lazy, as I like 'for' better
: > than 'while' as a construct. But that is just opinion.
:
: Oh, it is lazy. We can be sure of that. I was referring to defining a
: filehandle's lazy as precisely "reading each line as we need it and no
: more". That way intermediate calls to =$fh DTRT. But there are
: implications of that, particular when taking about =$fh not in the
: context of a simple for loop.
And now consider what it takes to make sure that
$line = =$*IN;
exec "cat";
can successfully make the second line visible to cat on standard
input, even if standard input is coming from a pipe. Even Perl 5
doesn't quite get this right--you have to write your own nibbler in
sysread to defeat the buffering. On the other hand, buffering your
input is probably the right default answer for performance reasons.
The shells do suffer from having to nibble pipes one byte at a time.
Larry
