in reply to Re: (Seemingly) Broken interactions between Net::Server and IO::Pipe?
in thread (Seemingly) Broken interactions between Net::Server and IO::Pipe?

Nope, what you're seeing is exactly the broken behavior that I mentioned. This section:
sub process_request { my $self = shift; my $x = Feeder->new(); my $line = $x->get_line(); print "Line = $line\n"; }
should be reading the first line from the client file, so $line should be #!/usr/bin/perl -w. The fact that it's not set to anything means that the pipe's not working. I'm running with 5.8.8 under Linux as well. IO::Pipe is identifying itself as version 1.13 and Net::Server is version 0.90.

Replies are listed 'Best First'.
Re^3: (Seemingly) Broken interactions between Net::Server and IO::Pipe?
by tcf03 (Deacon) on Mar 08, 2006 at 07:25 UTC
    I have never used IO::Pipe before, but from the docs it looks like you need to do a
    while(<$pipe>) { read from pipe... }
    when I run it it cats out the file fine, Id probably replace IO::Pipe with a routine that reads the file one line at a time. At least from what Ive read, that seems to be the desired effect.

    BTW, when running this code on Cygwin, I get the following:
    ted@skywalkerii ~ $ perl 2006/03/08-02:31:02 CONNECT TCP Peer: "" Local: "127.0.0 +.1:8097" Use of uninitialized value in concatenation (.) or string at + line 23. Got: >Line = < #!/usr/bin/perl -w # client use strict; use IO::Socket::INET; my $sock = IO::Socket::INET->new(PeerHost => 'localhost', PeerPort => 8097, Proto => 'tcp', ); die "Unable to connect" unless $sock->connected(); while (my $receive = <$sock>) { print "Got: >$receive<\n"; }
    after copying to /home/ted/foo/client

    "That which we persist in doing becomes easier, not that the task itself has become easier, but that our ability to perform it has improved."
      --Ralph Waldo Emerson
      You're still missing the point. :-)

      The 'cat' output is appearing on the stdout/stderr *of the server*, not in the client. The fact that the "Got:" is showing en empty string (well, just a newline, actually) indicates that nothing's getting from the server to the client. Instead, the Feeder object is failing (effectively) to do anything.

      By the way, I'm using 'cat' here as an example. The real application is running a much more complex command that's producing real output.

      As for reading from <$pipe>, that's exactly what it's trying to do. It's just stored $pipe inside $self and needs to extract it in order to read from it.