Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AsyncSSH - Screen Width Issues #338

Open
AlexLardschneider opened this issue Jul 1, 2024 · 4 comments
Open

AsyncSSH - Screen Width Issues #338

AlexLardschneider opened this issue Jul 1, 2024 · 4 comments
Labels
bug Something isn't working

Comments

@AlexLardschneider
Copy link

Describe the bug

Hey Carl!

Been switching from using system transport to AsyncSSH, and I am encountering the same issue we already saw in scrapli/scrapli_community#18. Even though I am increasing the screen-width using the CLI command on the device, it seems to be ignored since the output still contains line breaks.

It looks like this can be fixed by setting the term_size argument during asyncssh session opening (transport.py#221)

self.stdin, self.stdout, _ = await self.session.open_session(
    term_type="xterm", term_size=(256, 256), encoding=None
)

Unfortunately, currently there is no way to set this argument except patching the transport.py file manually.
Maybe we should add the possibility to add user-defined **kwargs to this open_session method, like we can for system transport?

Let me know if and how you'd like this implemented (or maybe there is already a way to fix this which I overlooked?), and I can create a PR to solve this.

To Reproduce
See scrapli/scrapli_community#18

Expected behavior
See See scrapli/scrapli_community#18

OS (please complete the following information):

  • OS: Linux
  • Scrapli Version: 2024.01.30
@AlexLardschneider AlexLardschneider added the bug Something isn't working label Jul 1, 2024
@carlmontanari
Copy link
Owner

hey @AlexLardschneider 👋

makes sense! can we support it with the existing transport args like in here? I didnt look too closely yet but I just remember we have at least some capacity to pass arbitrary/semi-arbitrary stuff to asyncssh. if this doesn't work though we can for sure make this work in one way!

@AlexLardschneider
Copy link
Author

Hey @carlmontanari, let me see what I can do.

@carlmontanari
Copy link
Owner

hey @AlexLardschneider did ya get this sorted ? anything we need to do here?

@AlexLardschneider
Copy link
Author

Hey Carl, things are pretty hectic at the moment, but I haven't forgotten about this.
I'll jump on it when I find some free time!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants