Support exec

[casey]

I'm writing a command wrapper and would like to exec the command I'm running, so that the process tree doesn't show the intermediate wrapper.

I looked in the standard library, and was surprised to see that exec is provided on unix:

https://doc.rust-lang.org/std/os/unix/process/trait.CommandExt.html#tymethod.exec

What do you think about a cmd_exec! macro? The return type would be fixed to io::Error, since in the success case it does not return.

[soenkehahn]

Yeah, that seems like a good idea. At least if it's not too complicated to implement. But I don't think it should be.

I wouldn't want to export it by default. But putting it into an e.g. exec submodule sounds fine.

[casey]

I wonder if there should be some kind of speedbump to prevent users from using it without realizing that it's platform-dependent, i.e. it doesn't work on windows. The exec function in the standard library is on std::os::unix::process::CommandExt, so perhaps we should mirror that. Maybe define cmd_exec in cradle::os::unix?

[soenkehahn]

Yeah, that seems good too.

I had hoped that the generated documentation would show a This is supported on Unix only. label if an item has a #[cfg(unix)]. But that doesn't seem to be the case, at least when building documentation locally. How can we get such a label?

[soenkehahn]

Or maybe cradle::unix is good enough? And would make it clearer at the top-level, what's going on.

[casey]

I think cradle::unix is probably good. It seems unlikely that we'd have arch-specific stuff, for example, that would make two levels necessary.

I think that you only get that label if you use an attribute like #[doc(cfg(unix))], which seems to be unstable. I only skimmed the issue though, so I could be misunderstanding what that attribute does.