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....