Re: [PEPr] +1 for Testing::Testing_DocTest

On Wed, Mar 19, 2008 at 8:59 AM, David Jean Louis <izimobil@gmail.com> wrote: > > > > > > The various proc_* calls will have a hard time functioning properly on > Windows. I've also had issue with proc_close() returning the proper exit > code and had to rely on piping it out to a 4th stream in order to get a > valid value on every run. See PHPT's CodeRunner_Driver classes for examples > of what I had to do with proc_open() and how to execute against WScriptShell > using the COM object on Windows. The latter is still a bit rough around the > edges, but will get you started. > > > > Well the package runs pretty well on windows (I only tested it on a > vmware winXP version), as for exit codes I didn't have this problem. > Thanks for the link anyway, I'll take look. > > David. > On the proc_* exit codes, I can point out my experience with it, which I added as a comment on the *proc_open()* manual page [1]: *ashnazg at php dot net* 05-Oct-2007 02:23<http://www.php.net/manual/en/function.proc-open.php#78305> It seems that if you configured --enable-sigchild when you compiled PHP (which from my reading is required for you to use Oracle stuff), then return codes from proc_close() cannot be trusted. Using proc_open's Example 1998's code on versions I have of PHP4 (4.4.7) and PHP5 (5.2.4), the return code is always "-1". This is also the only return code I can cause by running other shell commands whether they succeed or fail. I don't see this caveat mentioned anywhere except on this old bug report -- http://bugs.php.net/bug.php?id=29123 It looks like "Example 1998" is now listed as "Example #1" on that manual page. Also, I should point out this behavior wasn't specific to Windows... I was working on Linux when I ran into it. But, it was enough to remove the *proc_** methods from my usage, given my current environment. -- CRB [1] -- http://www.php.net/manual/en/function.proc-open.php