Re^5: Is there a problem with IPC::Open on Windows 7?

[glasswalk3r]

Maybe a bug opened to update the documentation would be a good idea? There are couple of workarounds for IPC::Open3, but none seems to be able to reach core.

Anyway, it seems to be possible to dup() sockets under MS Windows and use select() over them, but as I replied before, I need to do more tests with it.

[BrowserUk]

it seems to be possible to dup() sockets under MS Windows and use select()

Really? How would that work?

To the best of my knowledge -- which I thought was pretty good on this subject -- Perl's select is implemented in terms of the winSock select() function which will always return WSAENOTSOCK if any of the descriptors in the set is not a socket.

[glasswalk3r]

Really? How would that work? To the best of my knowledge -- which I thought was pretty good on this subject -- Perl's select is implemented in terms of the winSock select() function which will always return WSAENOTSOCK if any of the descriptors in the set is not a socket.

I'm not a MS Windows specialist and I cannot give all the details of how it works since I copying implementation code from others, but so far it is working 100% for STDOUT, and some initial testing for STDERR is looking good too.

Here is one implementation which I based mine: https://github.com/lucastheisen/ipc-open3-callback

And here is my implementation (take a look at Siebel::Srvrmgr::Daemon run() method and Test::Siebel::Srvrmgr::Daemon runs_with_stderr() method): http://code.google.com/p/siebel-monitoring-tools/source/browse/

Specific to the runs_with_stderr method, the test is not complete (the return code is being get from the Log::Log4perl log method) but if you keep the default logger configuration (see Siebel::Srvrmgr) you will get the STDERR from the srvrmgr-mock.pl script (included in the distribution).

[BrowserUk]

Here is one implementation which I based mine: https://github.com/lucastheisen/ipc-open3-callback

Okay. That makes more sense than your original description -- though I see how you arrived at that description.

Essentially, they are doing the same thing as Win32::SocketPairopen2() and Win32::SocketPairopen2_5() (original author:salva), in that they are redirecting the outputs from the commands via socket pairs, which are selectable.

I'm like the idea of IPC::Open3::Callback. It is a very clever way to address both the problems with IPC::Open3.

However, as it stands, it steals both the pid of the subprocess, and the stdin; which make it less useful than it could be. I can see myself stealing the idea of the callbacks and producing my own version that corrects for those. (Assuming the author doesn't modify his interface before sending it to cpan :)