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 control over the running procs use IPC::Run3, IPC::Run, IPC::Open3 >or one of the other perl modules that afford you specific controls over the standard filehandles >(per exec, system or run), or use an engine that does not require hijacking the handles for its >own purposes I do not believe there _can_ be a generalized fix for all engines >-- some _require_ stdio control to function. My scenario is the Catalyst web app is a product control panel and I want to be able to 1. fork off a /bin/tar to unpack an archive in the customer directory 2. fork off a /bin/mysql and pipe a proforma .sql file into it to create an application database In both cases picking up the exit status. Total time to run these is < 1 second so I'm happy for the web app to wait on them. Both of these were hard to do under Catalyst even using IPC::Run. Regards, Peter _______________________________________________ List: [email protected] Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
