Re: Windows weirdness after fork, dup2

Okay, if I'm not mistaken your "if" statement has problems. What is the difference between saying "if fork is not defined to $f" and "if $f is not defined". You fork, and then completely bypasses it. Your outputs show this - 1, then Parent equals PID (which will show because it IS the parent) and then as a normal program its shows 2,3,4. The if statement is just jumped! You don't even test within that fork. Basically you are creating a successful fork and then ignoring it with your "if" statement by having two negations to the fork. Hence why later on its starts reading itself. The parent isn't reading itself, it's just being a parent and outputting to STDOUT like any other program. I bet if you cut out the whole "if" bit you'd get the same result.

Where you have written your child process is where you parent should be, IF you have the "if" statement correct.

Hope that helps

Dean

Programming these days takes more than a lone avenger with a compiler. - sam
A Standard for the Transmission of IP Datagrams on Avian Carriers

Comment on Re: Windows weirdness after fork, dup2

Replies are listed 'Best First'.
Re: Re: Windows weirdness after fork, dup2 by sgifford (Prior) on Mar 06, 2004 at 17:05 UTC
The `=` in that line is the assignment of the return value from `fork` to the variable `$f`. `fork` returns `undef` if it fails, `0` in the child, and the child's PID in the parent. So if the fork fails, there's only one process, and it `die`'s. Otherwise, the child starts executing inside the `elsif (!$f)` block, and the parent executes the rest of the program. You can see this by having the different chunks of code print out PIDs. Plus, it works under Unix, which indicates that the code is generally correct.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re: Re: Windows weirdness after fork, dup2
by sgifford (Prior) on Mar 06, 2004 at 17:05 UTC

The = in that line is the assignment of the return value from fork to the variable $f. fork returns undef if it fails, 0 in the child, and the child's PID in the parent. So if the fork fails, there's only one process, and it die's. Otherwise, the child starts executing inside the elsif (!$f) block, and the parent executes the rest of the program. You can see this by having the different chunks of code print out PIDs.

Plus, it works under Unix, which indicates that the code is generally correct.

[reply]
[d/l]
[select]