Wade wrote:
I do not get what you are pushing for -- from what I have seen normal
catalyst code acts like normal perl code, except when the type of engine
you are using requires its own stdio redirects -- in which case it must
handle these in/outputs differently.
If you want to have full
On Mon, 17 Mar 2008, Peter Edwards wrote:
In Chart::Graph::Gnuplot latest it looks like line 768 is in _exec_gnuplot()
which calls system() to run gnuplot.
There are known problems getting the exit status back from a spawned process
under Catalyst.
I hit this a while ago. I didn't manage to
Gene Selkov wrote:
But I would also like a competent answer to this question: what can be
done to make the normal Catalyst code interact with unix processes
on all 3 channels? I mean, all 3: if a process spews something on
stderr, I'd like to capture that, consider how severe the message is
Gene Selkov [EMAIL PROTECTED] wrote on 03/20/2008 08:26:22 AM:
On Mon, 17 Mar 2008, Peter Edwards wrote:
But I would also like a competent answer to this question: what can be
done to make the normal Catalyst code interact with unix processes on
all 3 channels? I mean, all 3: if a process
[info] test powered by Catalyst 5.7012
You can connect to your server at http://trillian:3000 exit value =
16777215 signal number = 127 dumped core = 128 at
/usr/local/share/perl/5.8.8/Chart/Graph/Gnuplot.pm line 768 [info] ***
Request 1 (0.143/s) [13684] [Sun Mar 16 22:16:47 2008] *** [debug]
