in reply to exec on Windows "halfway forks"

And, does someone know a better way to "restart myself"?
I would use $^X instead of $Config{perlpath}, since the perl executable might not be where it was configured for it to be. No need to "use Config" to get $^X.
However the behaviour I am experiencing, does not match this either. Instead, I get a CMD.EXE shell plus my Perl program in parallel! Any explanation for this?
If you want really interesting behavior, try this in the dummy code:
while(1) { sleep(5); my $x=scalar<>;print "running $$:$x\n"; }
Then you'll see that when that thread comes out of sleep, it grabs stdin. Otherwise, the CMD shell has it.

My guess is that the parent thread, started with the relative path, starts a new thread with the EXEC and then exits, giving control back to the shell. The child thread (started with an absolute path) inherited stdin & stdout, so its input & output are interleaved with the command window.

My suggestion is to not respawn. Just overwrite $0!

$0=rel2abs($0) unless file_name_is_absolute $0;
That is, "lie" to make it look like your script was started with an absolute path.

Replies are listed 'Best First'.
Re^2: exec on Windows "halfway forks"
by ikegami (Patriarch) on Jun 14, 2010 at 17:46 UTC

    My guess is that the parent thread, started with the relative path, starts a new thread with the EXEC and then exits,

    (New process, not new thread)

    But what's causing it to exit? An exec emulation should wait for the child to finish. And it does last I checked. (My Windows system is down, at the moment.)

      You're right, even though this is windows we're talking here, exec really is starting a new process.
Re^2: exec on Windows "halfway forks"
by rovf (Priest) on Jun 15, 2010 at 11:18 UTC
    My suggestion is to not respawn. Just overwrite $0! $0=rel2abs($0) unless file_name_is_absolute $0; That is, "lie" to make it look like your script was started with an absolute path.
    This would not do here. The point is that I want to see the process using the absolute path in the Windows Process table (for example, when looking at it using, say, Process Explorer http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx.

    -- 
    Ronald Fischer <ynnor@mm.st>