Support for long-running command output?

[allComputableThings]

Is it possible to incrementally receive command output.
Suppose I wanted to run: 'tail -f /var/log/log.log'
... the commend will never complete. Is there something like await conn.read() to wait on the socket for more data?

Thanks in advance.

[carlmontanari]

Hey @stuz5000

Yep, TL;DR is disable transport timeout by setting that value to 0. You can then call as many channel.read as you want in a while loop or whatever you need to do. Something similar to:

        output = b""
        while True:
            new_output = await self.conn.channel.read()
            output += new_output
            if read_until in output:
                return

            await asyncio.sleep(1)

Or obviously just keep reading or do whatever you want!

You may not need to disable the transport timeout -- it governs the actual individual read operations... offhand I think its like 30s default or something, so if you never have any times where the channel goes more than 30s without output it wont matter, but probably a good idea to disable it for things like what you are talking about.

[allComputableThings]

Isn't there a solution that can await on IO instead of using await sleep in a loop and using consuming CPU? I think one of the intended benefits of switching to async/await in the first place is to remove the need for this (and also remove the complexity of epoll/select). Thanks, - Stuart

…

On Mon, Feb 7, 2022 at 9:43 AM Carl Montanari ***@***.***> wrote: Hey @stuz5000 <https://github.com/stuz5000> Yep, TL;DR is disable transport timeout by setting that value to 0. You can then call as many channel.read as you want in a while loop or whatever you need to do. Something similar to: output = b"" while True: new_output = await self.conn.channel.read() output += new_output if read_until in output: return await asyncio.sleep(1) Or obviously just keep reading or do whatever you want! You may not need to disable the transport timeout -- it governs the actual individual read operations... offhand I think its like 30s default or something, so if you never have any times where the channel goes more than 30s without output it wont matter, but probably a good idea to disable it for things like what you are talking about. — Reply to this email directly, view it on GitHub <#212 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3QJLE4EE6ZIKPO22OG3ZLU2AADTANCNFSM5NWVMDDQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[carlmontanari]

channel.read does exactly what you're saying. you can chose to sleep or not, just an example.

[allComputableThings]

Oh -- I misread and didn't see that it was *await* self.conn.channel.read. Thank you.

…

On Mon, Feb 7, 2022 at 9:51 AM Carl Montanari ***@***.***> wrote: channel.read does exactly what you're saying. you can chose to sleep or not, just an example. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

[carlmontanari]

No worries. Holler if that doesnt do what ya want and we can try to see if we can figure it out!