Closed mcky closed 1 month ago
Not sure what I think of this as its a lossy operation.
Would you be open to any API that exposed the underlying std::process::Command
?
Would you be open to any API that exposed the underlying std::process::Command?
What value is using assert_cmd::Command
giving you if you are then immediately wanting a std::prcoess::Command
?
Many of my other tests use cargo_bin
and the success/fail/stdout/stderr assertions via helpers, but for the odd interactive test I’m having to use rexpect
instead, and being able to get at the internal cmd
would save reworking them all.
Of course I don’t expect this merger just for my convenience, I just thought it might be generally useful to expose it in some manner (e.g. a getter or marking it public)
Considering we provide
it seems like if a std::process::Command
is needed, assert_cmd
shouldn't be in the way, so I'm not seeing a reason to move forward with this.
Allows conversion with
process::Command::from(asserted_cmd)
As mentioned in #212 I was having trouble serializing the value of the inner
std::process::Command
.After this PR the following should be possible: