When does exec cause a PID switch?-CodePudding

My boss wrote some code (I know - dangerous territory) in Perl years ago, and now it's causing a problem - the PID changes, so the pidfile is no longer valid. Code:

exec($0, "-f", "$configfile")

I think there may be a shell invocation involved that is forking $0 (cloning probably), but he's 1000% sure there's no shell involved. Is there another explanation for another process (a different PID) instead of an actual exec'd program in the same PID, for the code above?

BTW

exec("exec", $0, "-f", "$configfile")

works fine (the exec'd process has the same PID as before the exec function call).

Also, if there is a shell involved, how can I prove to him that that's the case?

CodePudding user response：

When you pass multiple arguments to system or exec, no shell is used. This contract is broken on Windows, where a shell is used if the program can't be executed without one.

When you use the block form of system or exec, no shell is used. Not even on Windows.

There's talk in the comments of exec creating a new process. That is not the case (outside of Windows).

#!/usr/bin/perl

use v5.14;

say "$$ @ARGV";

if ( !@ARGV ) {
   exec( $^X, "--", $0, "foo" )
      or die "exec: $!";
}

$ ./a
865
865 foo

CodePudding user response：

There is no fork, because exec receives 3 arguments. From perldoc -f exec:

If there is more than one argument in LIST, this calls execvp(3) with the arguments in LIST