The problem seems to be that IPC::Run on Windows offers only part of the documented features.
Then the question becomes:why continue to try and use a module that doesn't work on (on of) your target platforms?
The last few times I looked at IPC::Run--2 or 3 years ago now--it used very complicated and iffy mechanisms (at least on Win32), to try and achieve stuff, that could be done much more simply with built-in features like the piped-open. And not very successfully from what I saw.
If you are wedded to the use of that module, you'll need to talk to the author to look for fixes.
If you are not, and if you can describe the limitations you are encountering with the suggestion I made in Re: Windows-specific: Limiting output of created files, then I could try to suggest work arounds or enhancements to address them.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
| [reply]
[d/l] |
Hm. You seem to be specifying a moving target.
Originally, it was a windows equivalent of ulimit you were after.
Then you seemed to be mostly concerned with asynchronous execution.
Now you've dropped that in favour of:
- Obtaining the exitcode.
Is this going to be useful if you are going to kill the process per the original requirements?
- No shell interpretation.
Which belies the examples you posted in your OP which both use shell interpretation.
- A new requirement for separating STDOUT & STDERR.
- (And the portability requirement.)
It's almost as if this latest "requirements list" were taken straight from the IPC::Run features list. Which would be fine if it worked.
There have been many attempts by a lot of clever people to try and hide the differences between *nix and Win32 Process control, and to my knowledge, none of them have yet succeeded. Mostly because they tend to start with what works on *nix and then try to force Win32 to work the same way. These attempts are pretty much doomed to fail because the *nix solutions rely upon using select to prevent blocking IO, but Win32 pipes do not work with select. Win32 pipes have their own asynchronous mode of operation--several different modes--but they do not fit the *nix select model.
The single best possibility I have seen for the creation of a *nix/Win32 portable solution to the requirements you describe is salva's Win32::Socketpair, which exports a winopen2() command that is equivalent to IPC::Open2::open2(), but uses sockets instead of pipes between the parent and child processes. As win32 sockets do allow the use of select, this allows *nix asynchronous techniques to be layered on top of it successfully.
However, he stopped short of providing an winopen3() entrypoint which is what would be required to meet your latest set of requirements. I do not know whether he didn't try, or failed to succeed.
If you have a particular requirement for a win32 solution--that you can describe in sufficient detail that I can re-create the circumstances locally, and test locally--I can generally solve it. But I am not equiped to addressing theoretical, generic, cross-platform requirements.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply]
[d/l]
[select] |