Tracking Issue for `std::os::fd::CommandExt::fd`

[axelkar]

Feature gate: #![feature(command_pass_fds)]

This is a tracking issue for passing file descriptors in std::comand::Command with std::os::fd::CommandExt::fd.

Public API

// std::os::unix::process

pub trait CommandExt {
    fn fd(&mut self, new_fd: RawFd, old_fd: impl Into<OwnedFd>);
}

impl CommandExt for std::process::Command { ... }

Note: if a lifetime can be introduced to std::process::Command at any time in the future, we should make this use BorrowedFd.

Steps / History

• Feature request: [Feature request] Pass file descriptors in std::comand::Command #144191
• API change proposal: Pass file descriptors in std::comand::Command libs-team#623

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

• Implementation: None yet
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• Whether to name the function fd or pass_fd
• Is this also available on cfg(any(target_os = "hermit", target_os = "trusty", target_os = "wasi"))?

Footnotes

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

[tgross35]

The ACP mentions using pre_exec. As a note, this may not be the most performant API per @dominik-korsa's benchmarking https://rust-lang.zulipchat.com/#narrow/channel/327149-t-libs-api.2Fapi-changes/topic/Extra.20FDs.20in.20CommandExt/near/437952564.

[tgross35]

@joshtriplett was the param order of fn fd(&mut self, new_fd, old_fd) intentional? I keep getting a bit thrown off because dup2 uses (old, new) (I think that's also what I'd expect even without dup2)