rename `std.ChildProcess.exec` to avoid ambiguity with posix exec which replaces current image with new process

[tysonclugg]

The std.ChildProcess.exec function doesn't follow the expected behaviour of replacing the executable with the new program being exec'ed. See the SO question "Differences between fork and exec" for details on how fork and exec should behave.

Currently, std.ChildProcess.exec creates a std.ChildProcess instance and then calls its spawn method - returning an ExecResult struct:

zig/lib/std/child_process.zig

Lines 186 to 206 in f23987d

	pub fn exec(args: struct {
	allocator: *mem.Allocator,
	argv: []const []const u8,
	cwd: ?[]const u8 = null,
	cwd_dir: ?fs.Dir = null,
	env_map: ?*const BufMap = null,
	max_output_bytes: usize = 50 * 1024,
	expand_arg0: Arg0Expand = .no_expand,
	}) !ExecResult {
	const child = try ChildProcess.init(args.argv, args.allocator);
	defer child.deinit();
	child.stdin_behavior = .Ignore;
	child.stdout_behavior = .Pipe;
	child.stderr_behavior = .Pipe;
	child.cwd = args.cwd;
	child.cwd_dir = args.cwd_dir;
	child.env_map = args.env_map;
	child.expand_arg0 = args.expand_arg0;
	try child.spawn();

I expect that std.ChildProcess.exec should not fork or spawn, and it should have a !noreturn result (perhaps ExecError!noreturn with ExecError being much the same as a SpawnError).

[tgschultz]

However, coming from a Windows environment, this is not the behavior I expect. Should std.ChildProcess.exec be expected to follow POSIX definitions?

Perhaps instead of making it noreturn, it can simply be renamed to ChildProcess.spawn or ChildProcess.create to avoid confusion.

[daurnimator]

Yeah it might be best if we avoid exec at all.

Give that the module is ChildProcess, I don't think any "replaceCurrentProcess" doesn't make sense and belongs elsewhere (process.zig?).

[nektro]

any thoughts on run? doing some reworking in the above PR