Tracking Issue for command_resolve

[ChrisDenton]

Feature gate: #![feature(command_resolve)]

This is a tracking issue for providing more control of Command's resolution of executable files. See ACP#591

The libs-api team were divided on the shape and scope of this feature so this experiment explores multiple options in order to gather feedback. Please provide feedback if any of these are useful to you or you have other ideas.

Public API

// in std::process

/// Resolve the program to an absolute path by searching
/// the given paths for the executable.
pub fn resolve_exe(program: S, paths: I) -> io::Result<PathBuf>
where
S: AsRef<Path>.
I: IntoIterator<Item = P>,
P: AsRef<Path>,
{/*...*/

impl Command {
    /// Resolve the program by searching only the given paths for the executable.
    /// `paths` should be in the same format as `PATH`.
    fn resolve_in_paths(&mut self, paths: impl AsRef<OsStr>) -> &mut Self;

    /// If `PATH` is set on the child and `program` is not a path
    /// then force the program to be resolved as if the child `PATH` wasn't set.
    /// E.g. on Unix this may use `posix_spawn`.
    fn resolve_in_parent_path(&mut self, use_parent: bool) -> &mut Self;
}

Steps / History

(Remember to update the S-tracking-* label when checking boxes.)

• Implementation: #...
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• What shape should this API ultimately have?
• Instead of this. should we have platform-specific extensions for change the executable resolution in platform specific ways?
• Does this commit us, on every target, to always implement our own path resolution? (On some targets, we may be able to just defer to the OS for the actual execution, but these functions may still require reimplementing path resolution.)
• What about chroot? Should our path resolution take that into account, and what should it return?
• What about future extensions letting us use execveat/fexecve, where there's a file descriptor but no path?
• After the path is resolved, should the Command avoid re-resolving it, by reusing the resolution (e.g. to avoid a TOCTTOU)?

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩