Clear questions and runnable code
get the best and fastest answer
IPC::Run::run not working under mod_cgi on Windows?by larryk (Friar)
|on Jul 26, 2013 at 13:02 UTC||Need Help??|
larryk has asked for the
wisdom of the Perl Monks concerning the following question:
I'm trying to get GraphViz2 (v2.14 with GraphViz 2.30) to work in a CGI script under Apache (mod_cgi) on Windows.
In a command line context it Just Works and I get the expected SVG output. In the CGI context it gets as far as the call to fdp.exe, which never returns. Apache eventually times-out and gives up trying to serve the page. The fdp.exe (sub)process runs forever (until I kill it manually) with 0% CPU and ~3MB RAM.
I can simulate the issue by calling `fdp -T svg` with no input. That similarly waits forever for input.
GraphViz2 uses IPC::Run::run to call fdp.exe and it is supposed to provide input to fdp. Since this is working on the command line, I suspect it's an issue with IPC::Run::run and mod_cgi but I can't find any comments on the web about IPC::Run::run not working under mod_cgi on Windows with regards to passing STDIN to subprocesses :|
Here's the simplest example exhibiting the issue:
With IPC::Run debugging on (IPCRUNDEBUG=gory) I ran the script once on the command line (which works) and again as a CGI (which doesn't) to compare the debug output.
There are no error messages or warnings and except for the PIDs, about the only difference I can see is that as a CGI, all the paths (temp file, path to executable) contain double backslashes, whereas from the command line invocation the debug output has only single backslashes:
The input to fdp.exe is successfully written to a temp file in both cases and the fdp.exe process is successfully started in both cases.
I guess I'll just file a bug against IPC::Run and workaround the problem by snaffling the input to fdp.exe directly from the GraphViz2 object internals (gotta love Perl :) and calling fdp.exe myself NOT using IPC::Run. *shrug*
larryk perl -le "s,,reverse killer,e,y,rifle,lycra,,print"