Re^2: Basic IPC Example

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 &");
[download]

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

Comment on Re^2: Basic IPC Example Download Code

Replies are listed 'Best First'.
Re^3: Basic IPC Example by zentara (Cardinal) on Jul 25, 2007 at 12:04 UTC
*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 I'm not really a human, but I play one on earth. Cogito ergo sum a bum	[reply]

Replies are listed 'Best First'.

Re^3: Basic IPC Example
by zentara (Cardinal) on Jul 25, 2007 at 12:04 UTC

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

I'm not really a human, but I play one on earth. Cogito ergo sum a bum

[reply]