Pass input to the command output

[manojsethi]

Hello I have a situation in which I need to execute a command and then in result it ask for a password to enter. So a command is 2 step process that needs to be executed.

1. Pass the command with all required parameters. Wait for it to give the output.
2. If output contains word "Password", I need to pass the password and run the command to fully.

Can you guys please share your thoughts to achieve the same.

[Tyrrrz]

This is possible but not very simple. Basically, what you need to do is create a custom PipeSource for standard input, and fill it with data dynamically based on the output of the program.

Something like this (pseudocodish):

public class MyPipeSource : PipeSource
{
    public string Output { get; set; }

    public bool IsFinished { get; set; }

    public override async Task CopyToAsync(Stream destination, CancellationToken cancellationToken = default) =>
    {
        // Block until IsFinished is triggered, and then write the Output
        // Obviously can be optimized a bit
        while (!IsFinished)
            await Task.Delay(100, cancellationToken);

        // Encoding ideally passed to the pipe source or something
        var data = Encoding.UTF8.GetBytes(Output);
        await destination.WriteAsync(data, 0, data.Legnth, cancellationToken);
    }
}

And then do this (for example, could use other means to handle output progressively, including a custom PipeTarget):

var source = new MyPipeSource();
var cmd = source | Cli.Wrap("foo");

await foreach (var cmdEvent in cmd.ListenAsync())
{
    if (cmdEvent is StandardOutputCommandEvent stdOutEvent && stdOutEvent.Text == "Password")
    {
        source.Output = "SuperSecurePassword";
        source.IsFinished = true;
    }
}

Note that if the program decides to not consume standard input and exit early (for example if it doesn't ask for password), CliWrap will activate the PipeSource's cancellation token which will trigger it to silently throw (CliWrap swallows cancellation in that case) and continue.

Anyway, something like this. Let me know if this works.

[manojsethi]

Just wanted to share that my Password input is hidden masked input maybe that is causing that issue.

[Tyrrrz]

Do you know what error the process is producing?

[Tyrrrz]

Note that if you use ExecuteBufferedAsync() instead of ExecuteAsync(), the exception message will also contain buffered standard error. That may be useful to understand why the process returned an error.

[krisrok]

Sorry for necroposting, but this is the only helpful resource about "dynamic" input I found so far. In my case, the event stream stops just before the actual prompt I'm waiting for. I'm pretty sure in my case it happens because the prompt output and the input is happening on the same line, so no there's no line break that could trigger the StandardOutputCommandEvent. In my case it's because of a git add -p:

(1/2) Stage this hunk [y,n,q,a,d,j,J,g,/,e,?] <blinking cursor here>

I managed to work around it by spamming \n because in this case the prompt gets repeated :)

@Tyrrrz I wonder if there's a better way to handle dynamic inputs like this. Also because often these kind of prompts have a default value so spamming \n does not always work.

And, by the way, thanks for the great library! It's a pleasure to use after years of fiddling with ProcessStartInfo and the like.

[krisrok]

Ok, I think I get how it works now.

Maybe a chunked version e.g. ListenChunkedAsync() would be a nice addition to the execution models. It would just not split the received output to lines, so it'd use something like PipeTarget.ToDelegateChunked().
A potential issue with this could be unforseen split strings (buffer too small or whatever would cause the subprocess to flush early) which could mess up matching, e.g. user code looks for "ABC" but it gets split into multiple chunks of "AB" and "C".