Hi @DanielT
That's due to the specification of the SSH protocol. See
https://www.ietf.org/rfc/rfc4254.txt Chapter 6.5 (Starting a Shell or Command). The 'exec' message is specified to run a command and return all results till the command terminates (in some way), closing the connection. This is used in ExecuteCommand.
Maybe I didn't understand. The RFC says: "The program can be a shell, an application program, or a subsystem with a host-independent name".
So, shell, program or subsystem. `ExecuteCommand` is using 'program' in that case, right?
At the end of RFC says: "The server SHOULD NOT halt the execution of the protocol stack when starting a shell or a program. All input and output from these SHOULD be redirected to the channel or to the encrypted tunnel."
In my understanding is the opposite, ie, the client should not close the connection in 'shell' or 'program' mode.
ExecuteCommand has the advantage that you don't have to deal with the shell and have a real indicator on the termination.
Yes, this is want I need.
On the downside, the specification requires a separate connection to do so, resulting in quite some overhead if you want to execute many commands.
Separate connection or not was encapsulated into the component - we might not think about it.
The overhead is because 'sleep()' calls and closing connection...
'CD ..' has no output on its own, it just changes the current directory of the current shell.
I know that. However, I would like to show for users what is happening. If you try 'NonBlocking' , you will see that 'cd ..' brings data on 'OnAsyncReceive'. IMHO, both should have the same behavior... but this is not the main issue.
--
Hi @ViktorV
The shell channel particularity is that after command executing, using the TScSSHShell.ExecuteCommand method, the channel will be closed by the server after receiving a command execution result, regardless of a value of the TScSSHShell.NonBlocking property and a client cannot affect it.
I understood the behavior by design. However, I haven't understood why might be like that. What the advantages closing connection first?
Нou can connect to the server and send commands to the server using the TScSSHShell.WriteString or TScSSHShell.WriteBuffer methods, after their execution the channel is not closed:
Yes. The problem is that I don't know when all data has finished. That's why I would like to use `ExecuteCommand`, which uses 'ReadAllData' protected method - not public, not available.
The 'sleep()' calls I can just remove, replace by events (callbacks) or just decrease the number. But I would like to understand the disadvantages, if I remove `SetConnected(False)` and related code.
Thanks.