-
-
Notifications
You must be signed in to change notification settings - Fork 15k
std::process::Command no way to handle command-line length limits #40384
Copy link
Copy link
Open
Labels
A-processArea: `std::process` and `std::env`Area: `std::process` and `std::env`C-feature-acceptedCategory: A feature request that has been accepted pending implementation.Category: A feature request that has been accepted pending implementation.T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.Relevant to the library API team, which will review and decide on the PR/issue.
Metadata
Metadata
Assignees
Labels
A-processArea: `std::process` and `std::env`Area: `std::process` and `std::env`C-feature-acceptedCategory: A feature request that has been accepted pending implementation.Category: A feature request that has been accepted pending implementation.T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.Relevant to the library API team, which will review and decide on the PR/issue.
Type
Fields
Give feedbackNo fields configured for issues without a type.
The arg method doesn't track the total resulting command-line length and has no way of indicating to clients that the resulting command-line length would exceed the OS's underlying maximum length. This is fine for launching subprocesses with dozens of arguments, but renders it impossible to implement xargs or similar functionality.
Can I suggest a new method
fn try_add_arg<S: AsRef<OsStr>>(&mut self, arg: S) -> Option<S>with documentation saying that it's only preferable to
argwhen you're wanting multi-kilobyte command-lines?try_add_argwould keep track of the number of args already added, and if the number of args or the resulting length would exceed the OS limits, then it ignores the argument and returns it back to the client. Otherwise it acts like the normalargmethod and returns None.