in reply to Re^2: Nested line buffered output
in thread Nested line buffered output

The problem is in the title: "line buffered". You're reading P2 line-by-line, but printing only one line total in p2.pl in the first place. Try this in p1.pl: 

#!/usr/bin/perl

use strict;
use warnings;

$|=1;

my $p2 = "./p2.pl";

open(P2,"$p2 |") || die "P2: $p2 - $!\n";
while( read( P2, $_, 1 ) ) { # fixed as per [ikegami]'s post below
    print;
}

[download]

BTW, you should probably be using a lexical filehandle, but given the short example I won't complain too loudly. ;-)

Update: fixed bug in read as pointed out by ikegami in Re^4: Nested line buffered output.

Replies are listed 'Best First'.
Re^4: Nested line buffered output
by ikegami (Patriarch) on Jun 01, 2010 at 18:38 UTC

    The fourth arg of read is wrong. It should be 0 or simply omitted.

    If you're going to read one character at a time, getc would be clearer. But I recommend reading all available data instead of one character at a time. You can do that using sysread since it returns all available data (up to the specified limit) as soon as any data is available.

[reply]
      Thanks for pointing out the error.

      The distinctions among read, sysread, and getc are useful, but any of them serve to point out the issue in the original node. I used read specifically because it is more flexible than getc and does interact properly with buffering if there is any. That may be preferable in some situations, but sysread may be preferable if bypassing buffers is desired as a rule.

      As an aside, although there is for perl 5.10.1 and 5.12.0 a note at the bottom of the entry for sysread in the perldocs about UTF and characters, the documentation for read is clearer at a glance about handling characters and not just bytes. That's not anything against the function, and it will probably be fixed in the docs at some point. It's worth noting if you're pointing the function out to people in the meantime, though, because you might want to mention that note stuck at the bottom of the entry.

[reply]

        I used read specifically because it is more flexible than getc

        I don't see how read is more flexible than getc at reading available characters in the pipe. sysread is more flexible since it can read multiple characters in addition to reading a single character. This also makes it much faster IIRC.

        I used read specifically because it [...] does interact properly with buffering if there is any.

        That means you specifically didn't chose sysread because it doesn't interact properly with buffered IO, yet one is much more likely to encounter unbuffered IO than buffered IO when dealing with pipes (because the former solves the OP's problem and it's required by select).

        but sysread may be preferable if bypassing buffers is desired as a rule.

        That's backwards. I didn't use sysread to bypasses buffers, buffers aren't used because I used sysread. In the rare circumstance that other code reads from the pipe, non-buffered IO will have to be used there too, but that's not likely to be a problem. In the much more likely circumstance that select is used on the pipe, you'd need sysread anyway.

        As an aside, although there is for perl 5.10.1 and 5.12.0 a note at the bottom of the entry for sysread in the perldocs about UTF and characters,

        Basically, it says sysread will work with character streams as well as byte streams. I don't see why I should be pointing that out.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom