From: Peter J. Holzer on
On 2010-06-26 14:32, Tad McClellan <tadmc(a)seesig.invalid> wrote:
> John Kelly <jak(a)isp2dial.com> wrote:
>> From ISBN 0-596-00027-8:
>
> What is ISBN 0-596-00027-8?

http://oreilly.com/catalog/9780596000271/

hp
From: John Kelly on
On Sat, 26 Jun 2010 09:32:20 -0500, Tad McClellan <tadmc(a)seesig.invalid>
wrote:

>John Kelly <jak(a)isp2dial.com> wrote:
>> On Sat, 26 Jun 2010 08:40:43 +0000 (UTC), Willem
>><willem(a)turtle.stack.nl> wrote:
>>>John Kelly wrote:
>
>>><>;
>
>> The output is the same, showing the first two <> diamonds read only one
>> line each, thus proving a bare <> is NOT list context.
>
>
>There is no "bare" <>.
>
>The <> in
>
> <>;
>
>is in a statement.
>
>The statement provides the context for <> (or for whatever else is
>in the stmt).

I meant "bare" without a while or foreach which forcibly provide
context.

>
>
>>>I'm pretty sure that a bare <> has void context, (which usually
> ^^^^^^^
> ^^^^^^^
>>> translates to scalar context).
>>
>> From ISBN 0-596-00027-8:
>
>
>What is ISBN 0-596-00027-8?

Programming Perl 3rd edition.

>
>
>> 2.7.3. Void Context
>> Another peculiar kind of scalar context is the void context. This
>> context not only doesn't care what the return value's type is, it
>> doesn't even want a return value. From the standpoint of how functions
>> work, it's no different from an ordinary scalar context.
>
>
>Why do you quote that?
>That is, what point are you trying to make by quoting that?

It says void context is a "kind of scalar context." So according to the
author, void == scalar for purposes of knowing whether <> reads one line
or many.


>
>I almost called Willem on the "usually" part, until I re-read
>the "Context" section in
>
> perldoc perldata
>
> ...
>
> User-defined subroutines may choose to care whether they are being
> called in a void, scalar, or list context.
>
>void context always translates to scalar context for built-in functions.
>
>void context usually translates to scalar context for user-defined functions.
>
>
>So the nameless book you quote above is in error.

I see it gets deep.


>It should have qualified "functions":
>
> From the standpoint of how built-in functions work, ...
>
>
>> Yes, but I coded this test to determine what a bare <> does.
>
>
>That's done easily enough with a simple one-liner:
>
>bash-4.0$ perl -we '<>'
>foo
>bash-4.0$
>
>Since the program exited after only one input line, then the
>readline() must have been in scalar context, else it would have
>waited for more input rather than exit()ing. As we can see with:
>
> perl -we 'print <>'
>
>Note that here print() provides the (list) context for <>, and that
>the statement provides the (void) context for print().
>
>
>>>I don't know if <> is smart enough to recognize void context though,

>Since it is a built-in, void context is treated the same as scalar context.

My stupid test verified that.



--
Web mail, POP3, and SMTP
http://www.beewyz.com/freeaccounts.php

From: Dr.Ruud on
Ben Morrow wrote:

> my $data;
> while (<>) {
> chomp;
> length or next;
> $data = $_;
> last;
> }
> {
> local $/ = \2048;
> 1 while <>;
> }

This nicely keeps memory usage limited.
I always use 4096.

An alternative is to seek to the end:

seek STDIN, 0, SEEK_END;
<>;

--
Ruud
From: John Kelly on
On Sat, 26 Jun 2010 18:23:21 +0200, "Dr.Ruud" <rvtol+usenet(a)xs4all.nl>
wrote:

>Ben Morrow wrote:
>
>> my $data;
>> while (<>) {
>> chomp;
>> length or next;
>> $data = $_;
>> last;
>> }
>> {
>> local $/ = \2048;
>> 1 while <>;
>> }
>
>This nicely keeps memory usage limited.
>I always use 4096.

I decided to use 4096 too. I also replaced the "length" test with a
regex, to ignore lines containing only superfluous whitespace, prior to
the first line of data:

/^\s*$/ and next;


>An alternative is to seek to the end:
>
> seek STDIN, 0, SEEK_END;
> <>;

I posted, hoping for some magical Perl incantation. After all, there
are so many of them! But seek should be just as good. However, it also
needs a while loop that tests EOF.

Otherwise, the pipe writer could race with you, and write more data
after you seek, but before you read. Without a while loop testing for
EOF, you may falsely assume EOF, and close STDIN while the writer is
still sending more data, thus breaking the pipe.


--
Web mail, POP3, and SMTP
http://www.beewyz.com/freeaccounts.php

From: Ben Morrow on

Quoth John Kelly <jak(a)isp2dial.com>:
> On Sat, 26 Jun 2010 18:23:21 +0200, "Dr.Ruud" <rvtol+usenet(a)xs4all.nl>
> wrote:
>
> >An alternative is to seek to the end:
> >
> > seek STDIN, 0, SEEK_END;
> > <>;
>
> I posted, hoping for some magical Perl incantation. After all, there
> are so many of them! But seek should be just as good. However, it also
> needs a while loop that tests EOF.
>
> Otherwise, the pipe writer could race with you, and write more data
> after you seek, but before you read. Without a while loop testing for
> EOF, you may falsely assume EOF, and close STDIN while the writer is
> still sending more data, thus breaking the pipe.

Err... no. Pipes are not seekable, so the seek will simply fail. (Ruud
should have checked the return value of seek for exactly this reason.)

Ben