Output pipes

[Kim Helliwell]

Is there a way to pipe output to a command without the command blocking?
By that I mean: I want to start several xgraph (an x-window graphing app)
sessions from a Perl script, and so far, each session blocks until I dismiss
the window.

I tried:

open(GRAPH, "| xgraph &")

But that gives an error from xgraph that the data stream had errors.

I'm afraid I will have to invoke the whole fork/exec and IO redirection
machinery to do this, but I'd like to find a simpler way if anyone knows
one.

I have been reading the FAQ on system calls, and some of the questions come
close to helping, but not quite.

Any help appreciated. Email me (preferably) at (e-mail address removed)

Thanks,

Kim Helliwell

 

[Kim Helliwell]

Guess I wasn't clear. Without the &, it works, but blocks after
each process and waits till the process exits before going on to
the next one.

Kim

 

[xhoster]

Guess I wasn't clear. Without the &, it works, but blocks after
each process and waits till the process exits before going on to
the next one.

What does this mean? What is "it"? It blocks "after each process"....
does what? After each process starts up? After each process gets bored?
After each process exits? Under normal circumstance, I would think "after
a process" would mean after the process finishes and exits. But if it
blocks after the process exits and then unblocks when the process
exits....well, I don't see how that is a problem.

Xho

 

[Kim Helliwell]

Once again, forgive the imprecision. I guess I should have included
the context from my original post as well.

I'm piping output from a Perl script to xgraph, which is an X-windows
graphing application (that is, it has a GUI). So when xgraph starts,
it doesn't quit until I mouse-click to close it. And, the script blocks
until that happens. Clear so far?

OK, I want to spawn about 16-32 of these xgraph processes all at once,
instead of one at a time. So I would like my script not to block waiting
for exit of the first xgraph process before spawning the next, and so on.

The question is: how can this be accomplished, short of handling the
fork/exec and IO redirection myself? Can this be accomplished at all
using the open(GRAPH, "| $cmd") syntax?

I hope that is a bit more clear.

Kim

 

[Brian McCauley]

Kim Helliwell wrote upside down (please don't do that, it is considered
rude):

I'm piping output from a Perl script to xgraph, which is an X-windows
graphing application (that is, it has a GUI). So when xgraph starts,
it doesn't quit until I mouse-click to close it. And, the script blocks
until that happens. Clear so far?

OK, I want to spawn about 16-32 of these xgraph processes all at once,
instead of one at a time. So I would like my script not to block waiting
for exit of the first xgraph process before spawning the next, and so on.

The question is: how can this be accomplished, short of handling the
fork/exec and IO redirection myself? Can this be accomplished at all
using the open(GRAPH, "| $cmd") syntax?

AFAIK it is impossible to close a file handle opened using the pipe
syntax (either explicitly or implicitly through reuse) without waiting.
(I even thought this was a FAQ but I can't find it). You need to do the
pipe/fork/exec by hand or by using a different filehandle for each
process. This is most easily achived using autovivified
pseudo-anonymous filehandles.

open(my $graph, '|-', $cmd ) or die $!;
push @graphs => $graph;

 

[xhoster]

Once again, forgive the imprecision. I guess I should have included
the context from my original post as well.

I'm piping output from a Perl script to xgraph, which is an X-windows
graphing application (that is, it has a GUI). So when xgraph starts,
it doesn't quit until I mouse-click to close it. And, the script blocks
until that happens. Clear so far?

Sorry, still not clear. At what point in your script is it blocking?
upon the open of the file handle piped to xgraph? Upon any print to that
file handle? Upon printing over a certain number of bytes to that file
handle? Upon closing that file handle?

I don't see any reason it should block (for more than a brief time) at any
stage except the closing part. In which case, not closing the handles
would be one solution!

Xho