Feature request: add method to unix::process::CommandExt to set argv[0]

[jsgf]

In Unix, the first process argument is the executable name by convention. However, there are various occasions where you might want to set argv[0] to something other than the full executable path:

• to set a normalized program name
• to put multiple functions into one executable, selected by argv[0]
• to put commentary on the execution context for a process
• etc

I suggest adding a set_argv_0<S: AsRef<OsStr>(&mut self, arg: S) -> process::Command to std::os::unix::process::CommandExt to allow argv[0] to be overridden.

The default behaviour would remain unchanged.

It would require a little more implementation change - currently it always executes self.get_argv()[0], but this should be changed to self.program.as_ptr().

[bstrie]

This can be closed in light of #66512 , correct?

[jsgf]

yup

[glandium]

2 remarks:

• The doc points to this issue, should this be reopen and become a tracking issue?
• This is not a Unix-only feature. As a matter of fact, this also works on Windows (as playing with the executable argument of subprocess.Popen in python shows). So this should really be in std::process rather than std::os::unix::process.

[jsgf]

@glandium I don't know much about Windows, and my assumption was that it wouldn't apply, at least not directly.

Looking at

rust/src/libstd/sys/windows/process.rs

Line 165 in 1ce08f9

let mut cmd_str = make_command_line(program, &self.args)?;

it doesn't seem program is passed to the system separately from the command-line at all, so passing a different value for the first argument will just override the executable being executed. In the Unix model, the path to the executable and the first argument passed to it are independent (though conventionally related).

[glandium]

libstd passes null as first argument to CreateProcess

rust/src/libstd/sys/windows/process.rs

Line 205 in 1ce08f9

ptr::null(),

but it could be set to the actual executable, in which case the first "argument" in the command line would become argv0 in the launched process.
https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessw

[JohnTitor]

The doc points to this issue, should this be reopen and become a tracking issue?

I believe it should, re-opening.

[jsgf]

@glandium I had a quick look at implementing it for Windows, but it seems pretty complex.

• If we pass lpApplicationName, then Windows does minimal processing to it (nothing aside from adding the current dir if none is supplied). It doesn't add an extension.
• The existing Rust impl does a path search and adds a .exe extension, but none of that used if it can't find the file. In that case it falls back to whatever processing Windows does on lpCommandLine to find the executable.
• lpApplicationName must not be used for "16 bit applications" (.com files?). I don't know what happens with .bat files and the like - does it need to explicitly use cmd.exe as the lpApplicationName?

I had been hoping to spend a little bit of time to bring Windows to feature parity with Unix here, but I'm way out of my depth. I think this needs to be implemented and stabilized for Windows separately.

[KodrAus]

Since it looks like Windows support requires some more exploration and the feature as described has been stabilized, I'll go ahead and close this tracking issue. If anybody wants to drive Windows support that would be most welcome!