[Catalyst] Chart::Graph::Gnuplot trouble.

[Gene Selkov]

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 track it down quickly so I found
> a workaround using IPC::Run. That might work for you if you use the
> pseudo-ttys option.
>
> Cat-devs, any pointers as to what in Catalyst is interfering with process
> spawning and I/O redirection?

This has more to do with the kind of server you are running under than 
with the Catalyst itself. More specifically, it has to do with how the 
servers use the I/O, and yes, they do interfere. Most of them do.

The only combination I can use successfully is Apache/mod_perl. I run 
gnuplot and r with IPC::Run3. Fastcgi and the Catalyst dev server screw up 
STDIN (I believe they reopen and select() on it, but I am not sure). I 
have studied all available server implementations in detail, but I can't 
recall the details -- please forgive my vagueness. I was convinced that 
there is nothing a person with my level of competence could do to fix 
that.

So, I ended up running all my stuff under mod_perl (which I don't need 
otherwise), and I have to restart the server every time I change my code, 
which it quite a PITA, but I am grateful that there is at least one way to 
make things work.

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 (unless it 
tells me in the status code) and possibly throw an exception and 
ultimately forward the message to the browser.

I know I will be rebuked by the people thinking along the lines of 
"cross-platform compatibility". Spare me. I will still want to run 
gnuplot and a thousand other things, and talk to them through the unix 
I/O, because that's all they afford me to do.


Thanks,

--Gene