Tracking Issue for CommandExt::groups

[cuviper]

Feature gate: #![feature(setgroups)]

This is a tracking issue for std::os::unix::process::CommandExt::groups.

Sets the supplementary group IDs for the calling process. Translates to a setgroups call in the child process.

Public API

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

pub trait CommandExt: Sealed {
    fn groups(&mut self, groups: &[u32]) -> &mut Command;
}

Steps / History

• RFE: feature request: std::os::unix::process::CommandExt.groups() #38527
• Implementation: Add setgroups to std::os::unix::process::CommandExt #72160
• Final comment period (FCP)
• Stabilization PR

Unresolved Questions

• None yet.

[KamilaBorowska]

    fn groups(
        &mut self,
        #[cfg(not(target_os = "vxworks"))] groups: &[u32],
        #[cfg(target_os = "vxworks")] groups: &[u16],
    ) -> &mut process::Command;

I think the fact that groups uses a different type for VxWorks seems like a possible issue with the API. I understand that for backwards compatibility reasons gid uses a different type for VxWorks (albeit it may be worth fixing it anyway, see https://rust-lang.github.io/rfcs/1415-trim-std-os.html), but I see no reason to continue with this mistake for a nightly method.

[liff]

Is there a chance this will end up being stabilized, or is the type of the group ID a blocker here?

[Jisu-Woniu]

Any update on this? It's been half a year with no updates.