Repository navigation
SshCommand: OutputStream & ExtendedOutputStream should only return 0 when channel is closed #650
Description
Invoking Read(Byte[], Int32, Int32) on SshCommand*'s OutputStream or ExtendedOutputStream should blocking until either data is available, or the channel is closed (in which case zero should be returned).
We should strongly consider applying breaking changes to the SshCommand API as well:
- Change signature of
public string Execute()topublic void Execute(). - Have ExitCode throw when we have not received an ExitStatusRequestInfo.
- Remove the Result property (users should use OutputStream instead).
- Remove the Error property (users should use ExtendedOutputStream instead).
Reacted by vladd and Igor Milavec
Activity
drieseng commentedon Apr 5, 2020
I've disabled the
Ssh_Command_IntermittendOutput_OutputStream()integration test due to this issue.lucastheisen commentedon Jun 23, 2020
It would be nice to simply be allowed to supply our own streams (like
ProcessStartInfofor all in/out/err). Especially now that net core hasSystem.IO.Pipelines. I think the internalPipeStreamcould probably be replaced altogether. It would certainly reduce the element of surprise...IgorMilavec commentedon Mar 13, 2022
Just made a similar argument about API cleanup in #931... :)
What if we also removed/deprecated the
ExitCodeproperty and return the exit code from Execute/ExecuteAsync?Add SshCommand.ExecuteAsync
Add SshCommand.ExecuteAsync
Add SshCommand.ExecuteAsync (#1426)