I'll be honest, I'm not entirely certain what is going on here, but here are two versions that at least seem to work. Perhap's some kind monk can tell me (and the OP) why these seem to work properly.

if ($pid=fork() ) {
    select(undef,undef,undef,.1);
        open (STDOUT, ">test.txt");
    print "parent\n";
    
} else {
    print "child\n";
}
[download]

... and...

if ($pid=fork() ) {
    #select(undef,undef,undef,.1);
    print "parent\n";
} else {
    open (STDOUT, ">test.txt");
    system("echo child");
}
[download]

update: commented out the select line in second example.

The first one works as expected for me. Parent goes into the file, child goes to STDOUT. The second one does the same as mine. I've tested it on Activeperl 5.8.2 on WinXP Home and 5.8.3 on Win2000 Pro. It prints both child and parent into test.txt even though, from what I understand, the child shouldn't be able to manipluate the parent's STDOUT.

Commenting out the select line makes it likely that the parent will run it's print before the child does the open(STDOUT) which is causing the problem. You are then in a nasty state because then whenever the child get's arround to opening STDOUT, the parent's print statements will be spontaneously redirected. This is bad behavior.

It looks to me like something is broken in the fork emulation in ActivePerl.

I'd most likely agree with you, but to be honest I don't know to much about fork and how it's supposed to work. I am still in the process of studying the appropriate chapter in the Camel. But I do recall it mentioning that forks in perl were implemented with threads of some sort ( ithreads I think ) but was bent to more resemble a Unix Fork.

I do hope I made it clear in my first post that I didn't really know what was going on. I am however, curious why my first example seems to run as expected, or is this also a situation of the open happening after the other process has already printed it's message.

I'm also not entirely clear as to what select is doing. I can't seem to find any mention of that particular form in perlfunc. And neither of the two mentions in perlipc seem to say what they're doing.

Update: Ack, Just realized I should probably look in the camel, and managed to dig up what select is doing, apparently it's just putting a minor delay in one of the processes, I assume the purpose in the initial verion was to make certain that one process' print happened after the other's open, so it would seem that both my examples seemed to have the desired effect only due to (in one case) the random chance of one of the print's happening before the open. And in the other case because the open itself was delayed, making certain that the other process got it's print out beforehand. bleh...

Just Another Perl Alchemist

Ok, after a bit more research I would have to agree with esskar, apparently win32 children don't get their own STDOUT due to being implemented as threads. It would seem that the simplest solution would be to open a brand new filehandle in the child and just select it, as follows (which of course could be done in the $fh method, but I'm more comfortable with FH):

if ($pid=fork() ) {
    
    select(undef,undef,undef,.1);
    print "parent\n";
} else {
    open (CHLDOUT, ">test.txt");
    select CHLDOUT;
    system("echo child");
}
[download]

Now that I know better what's going on I'm pretty confident that this version will not only work as expected, but will actually work due to being done proper, instead of due to accident :)

i guess that under windows fork is implemented using threads so the child does not have his own STDOUT.

My guess is that that is indeed what is happening.

Why are you dont you open a new filhandle in each child process

Because he wants to use it together with system(), and that won't work as intended, with any other filehandle.

Update: Gee, Koosemose appears to be right, this does seem to work right (at least on Win98):

open CHILDOUT, ">test.txt";
select CHILDOUT;
system('perl -le "print q(Hello!)"');
[download]

I think that would indeed solve it.

According to Selecting on STDIN in Win32 and my own experience, on Windows select only works on sockets. You can work around this problem by creating a socket with socketpair, and using that instead.

I have some sample code for a very similar problem in Windows weirdness after fork, dup2.