in reply to Re^6: Windows-specific: Limiting output of created files
in thread Windows-specific: Limiting output of created files

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:

  1. Obtaining the exitcode.

    Is this going to be useful if you are going to kill the process per the original requirements?

  2. No shell interpretation.

    Which belies the examples you posted in your OP which both use shell interpretation.

  3. A new requirement for separating STDOUT & STDERR.
  4. (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.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Replies are listed 'Best First'.
Re^8: Windows-specific: Limiting output of created files
by rovf (Priest) on Apr 06, 2009 at 14:52 UTC
    You seem to be specifying a moving target.
    Well, not exactly, although I admit that it might look that way. The starting point for my task was to execute external programs from perl, where I have the program name and the arguments in an array, and where I need to catch stderr and stdout separately, where I need to fetch the exit code, and with the additional requirement that my program should run on Unix and Windows. From this, and after having learned that open3 gives problems on Windows, I developed my solution using IPC::run, which fulfils all these issues. What I simply overlooked at that time was the possibility that the program executed by 'run' might loop forever, producing output during the loop, and such fill up the disk.

    So I tried to fix this. Since I know a reasonable maximum size for the output file being produced, it is trivial to put under Unix a 'ulimit' in the the surrounding shell script which calls my Perl app. Not having an equivalent of 'ulimit' under Windows was what made me start this thread in the first place.

    I am not equiped to addressing theoretical, generic, cross-platform requirements.

    One solution would surely be to factor out the Windows- and the Unix-specific solution in different variants of a module, similar to how File::Spec::Functions masks whether we are using File::Spec::Win32 and File::Spec::Unix, but I had hoped someone would have a simpler solution. It looks that the issue is much more complicated than I expected it; thanks for your explanation of the differences between Win and Nix....

    -- 
    Ronald Fischer <ynnor@mm.st>
[reply]
[d/l]

In Section Seekers of Perl Wisdom