Pass output to GUI while command still running

[chucker]

I have a Xamarin Forms app that runs some CLI commands. A button is assigned to an AsyncRelayCommand that in turn invokes this async method:

    public async Task Netstat()
    {
        IsBusy = true;

        Output = "";

        await Cli.Wrap("/usr/sbin/netstat")
                 .WithArguments("-r")
                 .WithStandardOutputPipe(PipeTarget.ToDelegate(async s =>
                 {
                     await Device.InvokeOnMainThreadAsync(() => Output += s + Environment.NewLine);
                 }))
                 .ExecuteAsync();

        IsBusy = false;
    }

Output binds to a text box.

The goal here is, as soon as a full line has been written to stdout, it should be added to the text box.

Now, running netstat with host lookup takes a while. However, if I do so in Terminal, I immediately see some results. If I run the above code, I don't see any results until the entire command has run.

Is there something I need to do to force a different flush behavior? Are my assumptions correct (for example, the API doc for PipeTarget.ToDelegate seems to agree that it should flush on newline)?

[Tyrrrz]

This worked for me. The output was being written in real time and I could put a breakpoint to verify that it triggered on every line.

Are you sure the issue is not within await Device.InvokeOnMainThreadAsync(() => Output += s + Environment.NewLine);?

Maybe the value of Output is updated but the view is somehow not updating? Try to put a breakpoint inside the delegate and see what's going on.

[chucker]

(Note that this is on macOS, not Windows.)

I did put a breakpoint on the delegate — it invokes that a lot towards the end, and not at all before.

I also checked ListenAsync. As expected:

switch (cmdEvent)
{
    case StartedCommandEvent started:
        // gets invoked immediately
        break;
    case StandardOutputCommandEvent stdOut:
        // gets invoked many times towards the end
        break;
    case StandardErrorCommandEvent stdErr:
        // doesn't get invoked at all
        break;
    case ExitedCommandEvent exited:
        // gets invoked once at the end
        break;
}

However, apparently the issue is with now netstat behaves once it is piped. If I do netstat -r | cat, it has the same issue — it waits until all data has arrived.

Is there something I can do to make CliWrap behave… more like a shell, I guess? I'm not really sure how a terminal can get this data as a stream, but anything receiving stdout cannot.

(Oh, and thanks for the speedy reply! I've been using this library for a while, and it's greatly helped me for other use cases.)

[Tyrrrz]

Ah I didn't realize it was netstat on macos.
To be honest, I've never encountered something like this before. What you're describing sounds like netstat detects if the output has been redirected and changes its flushing strategy.

Just out of curiosity, does this work?

using var process = new Process
{
    StartInfo = new ProcessStartInfo("netstat")
    {
          RedirectStandardOutput = true
    }
};

process.OutputDataReceived += (_, args) => Device.InvokeOnMainThreadAsync(() => Output += s + Environment.NewLine).GetAwaiter().GetResult();

process.EnableRaisingEvents = true;

process.Start();
process.BeginOutputReadLine();

await process.WaitForExitAsync();

[chucker]

Just out of curiosity, does this work?

It does not — same behavior.

But that did lead me in the right direction to the solution/workaround, which is to wrap it in script -q /dev/null:

await Cli.Wrap("/usr/bin/script")
         .WithArguments("-q /dev/null /usr/sbin/netstat -r")
         .WithStandardOutputPipe(PipeTarget.ToDelegate(async s =>
         {
             await Device.InvokeOnMainThreadAsync(() => Output += s + Environment.NewLine);
         }))
         .ExecuteAsync();

This nicely streams results line by line!

So, that works for me (whatever tiny overhead there may be doesn't matter for my goal), thanks! However,

• it's platform-specific (e.g., the syntax on Linux is slightly different, and apparently, Linux with unbuffer and FreeBSD with stdbuf offer alternative approaches)
• it makes calling Cli.Wrap a little awkward, obviously.

Thus, I'm not even sure if this is feasible from .NET, but a feature request, I would really like a .WithPseudoTerminal().

[Tyrrrz]

To be completely honest, I'm not sure what makes a shell actually work like a shell, so I don't really know which piece is missing. However, given that it doesn't work with raw Process, I think our options are quite limited since we're ultimately using the API that .NET provides us. I would suggest to make a feature request on .NET directly, but like I mentioned earlier, I don't know exactly what to request. 😀 The bottom line is: if it can be done with Process it's likely doable with CliWrap, if not then it's definitely not doable with CliWrap. So I don't really know what the code for .WithPseudoTerminal() would look like.

Regarding the fact that it's platform-specific, I'd say it was platform specific from the beginning. It turns out there is netstat on Linux, macOS, and Windows, but they all work differently -- it just previously the difference in their behavior wasn't impacting anything, but the code was still in reality platform-specific. In any case, if you write a method like this:

Command Netstat()
{
    if (RuntimeInformation.IsOSPlatform(...))
       return Cli.Wrap("/usr/bin/script").WithArguments("-q /dev/null /usr/sbin/netstat -r");
   else if (...)
       return ...
}

await Nestat().WithStandardOutputPipe(PipeTarget.ToDelegate(async s =>
 {
     await Device.InvokeOnMainThreadAsync(() => Output += s + Environment.NewLine);
 }))
 .ExecuteAsync();

I don't think it's too horrible.