Open sunshowers opened 2 years ago
Could you give me an example of what you're imagining the API might look like, and compare that to doing the same thing with unchecked
today?
Digging up this thread - I want to run a command that will print its errors to stderr. I'd love to be able to do something like
let result = cmd!(...).run();
match result {
Ok(output) => { ... },
Error(err) => {
eprintln!("{}", err.stderr);
// ...
},
}
// vs unchecked
let result = cmd!(...).unchecked().run()?;
if result.status.success() { ... }
else {
eprintln!("{}", err.stderr);
}
It's definitely doable via unchecked
but as OP said duct is about doing commands the right way. To me, at least, dropping the (likely) root cause error messages from the command when the command fails by default seems wrong? To me at least I think that the rare case is wanting to just tell the user "this command failed" as opposed to "this command failed and here's why".
This can be done through use of
unchecked
today, but it would be great to have an ergonomic way to do so given how muchduct
is built around making the correct thing easier to do.The main challenge is that
wait()
etc return a&Output
, while Rust errors are generally'static
. stdout and stderr are unbounded so if we clone data, it can be quite expensive.Some thoughts:
String::from_utf8_lossy
while printing the data outio::Error
through aFrom
impl for compatibility