Closed li-lyoung closed 5 years ago
Hey Li.
This is partly of how GoExpect came to be, before this we just did session.Run and hoped for the best .. At least at the time this did not work very well with many, (any?) , of our vendors , even if the command managed to get executed the return codes was quite random.
Have had requests to expose the session object before but think we went with just using the *ssh.Client to create new session objects to do Run.
Thanks for the quick reply @skalle!
Have had requests to expose the session object before but think we went with just using the *ssh.Client to create new session objects to do Run.
Do you mean just create your own session object and pass it into SpawnGeneric instead of using the convenience SSH methods?
That could probably work but what was done there , don't really remember what they wanted the session for though , was:
So the expect session is never exposed , another one is created from the client to do whatever was needed there.
If you really need the expect session for something that'd not work.
Hey Li.
Did that explanation help or you still want to have access to the expect Session object?
Closing this as there's been no response for a while, reopen if that's in error.
Right now when using SpawnSSH/SpawnSSHPTY goexpect will create a SSH Session object and call the Shell method automatically. While this works great for lots of network devices, for other devices (ex: servers) it would be great to be able to call the Run method without creating a shell as that adds additional parsing complexity ($PS1, etc) when you only want to run a single command. I think exporting the underlying Session object could work or adding the command to run as an Option which would change logic in SpawnSSHPTY to call session.Run instead of session.Shell would also work.