Lack of API mutating args at std::process::Command

[cehteh]

My saying, still clearing the argument list for recreating it would be the most minimal functionality needed and is lacking currently. I would like to have an API that allows the mutation of an existing argument as shown above, because that is very common.

About the env-mess I'd wait and see what the solution on Why should std::env::var panic? will look like finally and then follow that route. Note that I put a comment there about that env keys may get their distinct type, dunno how feasible that is (to me it boils down to "will rust want to make things correct even when it introduces a breaking change or staying bug by bug compatible").

[zackw]

@cehteh

For args it is very common that one wants to update an argument at a certain position. I am thinking this really deserves to have an API, not for efficiency (which is irrelevant when we talking about spawning processes), but for ergonomic reasons with something like:

let mut command = Command::new("dosomething").args(["FILE"]);
somefiles.iter().for_each(|file| command.arg_set(1, file)?.spawn());

I have written many programs that needed to do things like this (not in Rust) and I would like to explicitly vote for the addition of .arg_set(index, string). It can easily be quite a bit hairier than @cehteh's example, e.g. from a Python script I wrote for work

proc = subprocess.Popen([BRO, "-b", "-C", BRO_SCRIPT,
                         "-r", input_file, "-w", "-"],
                        stdout=subprocess.PIPE, ...)

where the argument that changes for each file to be processed is third-to-last, and has to be there because of the way the process being run parses its arguments. In Python it's no big deal to create a scratch argument array for every invocation, but in Rust it would be quite a bit longer I think.

[cehteh]

What would be the way to progress here (only the 'arg' part)? Opening an issue, Writing an RFC or sending a PR?

I haven't done such yet and don't know the process. I can offer to do the coding for Linux/Unix, but don't know Windows and other platforms. Would be nice if someone cold lend me a hand.

[chrisd]

According to the guide:

New unstable features don't need an RFC before they can be merged. If the feature is small, and the design space is straightforward, stabilizing it usually only requires the feature to go through FCP. Sometimes however, you may ask for an RFC before stabilizing.

I'm not certain but it sounds like you could make a PR and there would be an FCP (where most of the libs team review the proposal).

Though if you're not sure you can ping @rust-lang/libs on a github issue or ask on zulip.

[yaahc]

As long as it doesn't change the stable API it wouldn't even need an FCP. Just make the PR and an associated tracking issue for it's eventual stabilization.

[cehteh]

I opened a related issue, will start on implementing this soon.

Mutate arguments at std::process::Command