Possibility to not redirect certain process streams

[Baune8D]

Details

Would it be possible to add functions for modifying redirect properties on ProcessStartInfo?

Certain CLI programs writes output that CliWrap does not seem to be able to replicate using a pipe to eg. Console.OpenStandardOutput().

An example of this is when running minikube start, there are lots of live progress and icons which comes out very strange when piping to Console:

Instead of this when invoking Process directly without redirecting output:

Sometimes i am not interested in parsing any output, i just want to execute the command in the console, and assert the exit code.

I would like to be able to keep using CliWrap for all CLI invoking needs, since the fluent api is so very useful.

[Tyrrrz]

The reason the output doesn't look right is that minikube manipulates the console window directly (by moving the cursor) when writing the output. I believe that not redirecting streams might not be enough, and you might also have to unset CreateNoWindow as well to allow the child process to properly take ownership of the parent process's console. I'm not sure, you'd have to test it.

The issue with not redirecting streams is that it will introduce diverging logic inside CliWrap that would have to be tested separately. Considering that 99% of CliWrap's functionality relies on piping, it doesn't make much sense.

I'd recommend using the raw Process for things like this. If you are not interested in piping, then it offers an adequate experience as it is. You can also use CliWrap's ArgumentsBuilder, EnvironmentVariablesBuilder, etc. with it if you want.

[Baune8D]

I completely understand your argument. My current workaround is to write a wrapper around raw Process as you described, in order to facilitate this use case, but i currently find myself duplicating alot of CliWrap's existing functionality.

I understand CliWrap being primarily focused around pipes, but i find it really good as a generic constructor for generel process execution. If this option was implemented in the future i do not see why CliWrap could not completely replace the use of Process.

However i understand and accept the answer you provided 🙂 Just a bit of feedback from my side 👍

[Tyrrrz]

I can empathize with the issue of having to use two tools for what seems like the same job. I've given it thought in the past, and there just doesn't seem to be a good and seamless way to add the no-piping scenario to CliWrap, from a design perspective. There are always going to be things that Process can do that CliWrap can't and that's fine – the former is a much more general purpose class, and most of CliWrap's utility comes from its focus on one very specific use case: running command line programs and getting their output.

[Baune8D]

Hi again @Tyrrrz

Since writing this issue, i have worked on my own solution to this problem and have been using it in a project for some time.

I have now extracted it into a fork of CliWrap called CliCommander, and was hoping to get your input on the project.

I would have preferred some kind of solution directly in CliWrap, but i can understand your reasoning behind this, so i hope you are ok with me maintaining this solution on the side.

It does borrow alot of code from CliWrap, and copies some internal classes that was needed.

I am not going to implement any further functionality into CliCommander, i just plan on aligning it with CliWrap whenever it gets updated.