Though I noticed this description of $SYSTEM_FD_MAX ($^F) in perlvar:

The maximum system file descriptor, ordinarily 2. System file descriptors are passed to exec()ed processes, while higher file descriptors are not.

# topen.pl
use strict;
use warnings;
open(my $fh, '<', "zz.tmp") or die "open zz.tmp: $!";
my $fdnew = fileno($fh);
print "fdnew=$fdnew\n";


# topensys.pl
use strict;
use warnings;
use Fcntl;
$|=1;

# $^F = 3;  # uncomment this line to inherit $fh_g

my $tmpfile_g = 'tmpglob.tmp';
open(my $fh_g, '<', $tmpfile_g) or die "error: open '$tmpfile_g': $!";

if (0) {
    # Fiddle with close-on-exec, works on Unix, not Windows.
    my $val = fcntl($fh_g, F_GETFD, 0) or die "error: fcntl: $!";
    # $val |= FD_CLOEXEC;   # turn on
    $val &= ~FD_CLOEXEC;    # turn off
    fcntl($fh_g, F_SETFD, $val) or die "error: fcntl: $!";
}

my $rc = system("$^X topen.pl");
sleep(30);
print "rc=$rc\n";
[download]

To run this test, first create empty tmpglob.tmp and zz.tmp files, then run topensys.pl, which forks topen.pl. The sleep is there so I could run OS file handle utilities to peek at what file handles each process had open.

This all worked as advertised on Unix, at least that's what I saw, both via the fd reported by topen.pl and confirmed by the lsof utility.

However, on Windows, it seems that the underlying OS file handle for the tmpglob.tmp file is being inherited by topen.pl; that's what sysinternals handle utility told me.

Before rushing off and perl-bugging this, I thought I better discuss it first in case I've missed something.

Since Windows does not support FD_CLOEXEC, you can't use Fcntl to work around this annoyance. Though Windows can support this behaviour (for example, via CRT O_NOINHERIT flag), I don't know of any way to get at it from pure Perl code. I was thinking a new close_on_exec() method for IO::Handle might be nice. Thoughts?