Open casey opened 3 years ago
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.
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
?
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?
Or maybe cradle::unix
is good enough? And would make it clearer at the top-level, what's going on.
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.
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 toio::Error
, since in the success case it does not return.