Re: Basic IPC Example

[kyle]

In your short example, you're likely suffering from buffering. A $|++ (see perlvar) in delayme.pl should take care of it. What's happening is that the output from delayme.pl is getting buffered on the way to its parent. If you leave it as it is but make the loop longer, you'll get a bunch of lines all at once, and and then another long pause while more lines build up in the buffer.

When it comes to bidirectional communication, you will eventually want to look into IPC::Open3 or IPC::Run for that. I've used Expect in the past too.

[wind]

You're right. Adding $OUTPUT_AUTOFLUSH to delayed.pl does make the piped open work as desired. However, using the suggestion in perlipc for Background Processes does not require any addition to delayed.pl.

# name: basicipc.pl (non-filtering version)
#
# Purpose: Receive the STDOUT from a secondary app and simply
# mirror it to our STDOUT.

my $cmd = 'perl delayed.pl';

system("$cmd &");

Why do these function different? I suppose it could be as simple as the fact that delayed.pl script detects where its STDOUT is being directed and chooses to buffer in the case of open with pipe. But then my question would be, is there a way for open to force delayed.pl to not buffer without having to edit delayed.pl itself? Maintaining that delayed.pl is a simulation of a real executable and not simply another perl script.

- Miller

[zentara]

Why do these function different? I suppose it could be as simple as the fact that delayed.pl script detects where its STDOUT is being directed and chooses to buffer in the case of open with pipe

I've been trying to figure that one out for quite sometime. This is my take, (and I may be wrong). When you feed a program with piped input, the program will wait until the input pipe is closed, before proceeding. Why? How does it know when input has ended?

When you run apps from a terminal, and feed it multiline input, you usually need to send a Control-D to signal "end of input.... now start processing it". Now the way you signal "end of input" in a pipe is to close it. See EOF character