sanketbajoria / ssh2-promise

ssh with promise/async await and typescript support
https://www.npmjs.com/package/ssh2-promise
MIT License
148 stars 25 forks source link

Shell/Spawn: Stream Encapsulation? #15

Closed MutableLoss closed 6 years ago

MutableLoss commented 6 years ago

Version: 0.1.1

Issue: It seems shell and spawn still use non-wrapped event handlers, so using promises, async/await isn't feasible for waiting for the shell output result.

Details: It seems no matter what I've tried, generators, promises, or async/await, every time the surrounding function is considered resolved after the listener being initiated, not after the stream data being passed like the exec and sftp methods.

Is there a specific use-case that is expected to be used with these methods to avoid having to use the abstraction pattern required by the base ssh2 library? So far the only methods I've found to be feasible is polling for the result, or making the listener the messenger, both which remove the ability to return to the instantiating scope.

Exec doesn't suffice, since I need access to the user environment via the tty. I had to do this with ssh2 as well. Suggestions, or possible feature addition in the future?

sanketbajoria commented 6 years ago

@3DEsprit Promises, async/await are only feasible for future response/result. That's why.. below command provide different result once completed.

Sorry i didn't understand this part So far the only methods I've found to be feasible is polling for the result, or making the listener the messenger, both which remove the ability to return to the instantiating scope.

Can you please elaborate more, what you are trying to do?

MutableLoss commented 6 years ago

It really isn't a horrible problem, it just changed the abstraction needed to handle the responses, and that was the misunderstanding. I initially thought the idea was to offer responses from each part of the wrapper.

I can certainly see the benefits of not wrapping the socket/stream, it was only in my use-case that these weren't a huge deal, since I'm only watch the data/close/error events.

Sorry i didn't understand this part

So far the only methods I've found to be feasible is polling for the result, or making the listener the >> messenger, both which remove the ability to return to the instantiating scope. Can you please elaborate more, what you are trying to do?

Sure thing!

I was having an issue using promises to handle the response data from the stream. I have a SSH/shell-based method in a separate class/method, and the issue was passing the response back to the initiating call method. Because of what was needed, I went ahead and used the pattern I used in the past with JS and ssh2, making each SSH method emit the response to a custom event handler once the close event is triggered.

All I'm really doing is using a shell to call commands since I need the user environment for the majority of them, but I'm also using it to receive the complete terminal response as well. It's not a horribly common use-case that I've seen.

I hope that makes more sense.

Anyways, it is all is good. I was really just curious what the intended abstraction was since the socket/stream was in the open.

MutableLoss commented 6 years ago

I'll go ahead and close this, since the encapsulation is to benefit the more powerful use-cases, which make complete sense. 👍