terminal icon indicating copy to clipboard operation
terminal copied to clipboard

Cannot scroll buffer in Terminal with inbox telnet client

Open sierrab1989 opened this issue 4 years ago • 24 comments

Hi, I love the new Windows Terminal. I've manage to add my routers and switches to it but the only issue I have is that I can't scroll. Once I log into my switch using ssh, I can't seem to scroll up to see what's above. Kindly let me know how I can activate scrolling. PS. scrolling works for regular CMD or PowerShell.

sierrab1989 avatar May 20 '20 19:05 sierrab1989

Hi, please make sure you're using the bug report template when you file issues.

What SSH client are you using?

DHowett avatar May 20 '20 19:05 DHowett

Hi Dustin, Actually I'm able to scroll through on SSH logins. I'm currently using the OpenSSH Beta. It's with Telnet that I'm not able to scroll.

Regards,

sierrab1989 avatar May 20 '20 23:05 sierrab1989

Cool. Which telnet client?

DHowett avatar May 20 '20 23:05 DHowett

for telnet i'm using the one that you add on the windows feature.

sierrab1989 avatar May 21 '20 17:05 sierrab1989

Hi, I'd just like to state that I'm seeing the same issue.

I'm using Terminal 1.0.1401.0

It's only happening with telnet, not SSH. I'm using the inbuilt Windows 10 telnet client.

It happens with both PowerShell and Command Prompt running in Terminal. I can successfully scroll using the old Console, with both Command Prompt and PowerShell.

I hope this helps.

shermp avatar May 28 '20 07:05 shermp

Hi, I'm using Teminal Preview 1.0.1402.0

  • Power Shell
> ssh junhwan@dell2
$ vi test.cpp

After connecting to ssh, when I edit the source with vi (vim), when I scroll the mouse, strange characters are displayed. I haven't experienced it in other ssh tools.

I use the set mouse=a option in the .vimrc file. This happens when using this option.

JunhwanPark avatar Jun 11 '20 11:06 JunhwanPark

Any chance getting this as higher priority? This is a bug that breaks compatibility with Microsoft's own existing functionality (telnet) and it could be a blocking bug that forces people dropping Terminal :(

szsong avatar Jul 29 '20 07:07 szsong

Is there the latest development of this bug?

Elinpf avatar Sep 10 '20 06:09 Elinpf

Nope. We'll make sure to update this thread when there is. In the meantime, might I recommend the Subscribe button? image That way you'll be notified of any updates to this thread, without needlessly pinging everyone on this thread ☺️

zadjii-msft avatar Sep 10 '20 13:09 zadjii-msft

It still not fixed...

cjsakfh89 avatar Jan 28 '21 07:01 cjsakfh89

@cjsakfh89 Nope, hence why this issue is still open. We'll make sure to update this thread when there is any progress. In the meantime, might I recommend the Subscribe button? image That way you'll be notified of any updates to this thread, without needlessly pinging everyone on this thread ☺️

zadjii-msft avatar Jan 28 '21 12:01 zadjii-msft

Folks please prioritize this item, this is rendering the app useless for many networking tasks. I've noticed the VS Code integrated terminal is working fine but Windows Terminal is broken, interestingly enough.

pmonajem avatar May 10 '21 22:05 pmonajem

Is there any workaround for this issue?

tarekeldeeb avatar Jun 09 '21 09:06 tarekeldeeb

same issue with version 1.9.1942.0

shadow1163 avatar Jul 30 '21 03:07 shadow1163

Is there any workaround for this issue?

I found a temporary solution. Plink from PuTTY works acceptable in this case.

As mentioned in PuTTY documentation, "Plink is probably not what you want if you want to run an interactive session in a console window" but it works with Windows Terminal even better than native MS telnet.exe

shaunthorne avatar Oct 10 '21 20:10 shaunthorne

Hi,

I confirm @shaunthorne 's workaround is working and is an acceptable solution in this case.

I've been trying to use Windows Terminal as the default console application for GNS3 network simulation software, and had the same buffering issues everyone is talking about. Using Plink works like a charm : wt -w0 split-pane --tabColor #C678DD --colorScheme "One Half Dark" --title %d --suppressApplicationTitle plink -telnet -P %p %h

thx

mosebac avatar Nov 24 '21 10:11 mosebac

Hi is there are any update further updates? my windows terminal version 1.11.3471.0 have same problem thanks

eddie813022 avatar Jan 04 '22 08:01 eddie813022

Nope. We'll make sure to update this thread when there is. In the meantime, might I recommend the Subscribe button? image That way you'll be notified of any updates to this thread, without needlessly pinging everyone on this thread ☺️

zadjii-msft avatar Jan 04 '22 11:01 zadjii-msft

I have the same issue with build-in telnet client. And I think, that I understand reasons for that behavior. Windows console have such thing as screen buffers and build-in telnet client use them. Also old console window does not actually have scroll-back buffer: all scrollable region is part of screen buffer, while in Windows Terminal screen buffer have size of the window. So you loose scroll-back because it leaves screen buffer, and it is very likely that build-in telnet client updates its screen buffer in such way, that it prevents Windows Terminal from capture scroll-back. For example, when remote side disconnect telnet session, as build-in telnet client display message about that, top four lines of remote session console screen get captured in scroll-back by Windows Terminal.

PetSerAl avatar Feb 05 '22 03:02 PetSerAl

The work around I used was wsl. wsl ~ --exec telnet 10.77.77.2

I saw others mention using plink, but when I control+c, plink would exit. Using WSL + telnet does not have this issue.

tatroc avatar Jul 14 '22 10:07 tatroc

The work around I used was wsl. wsl ~ --exec telnet 10.77.77.2

For those of you here trying to get GNS3 to use the new Windows Terminal (like me), I just want to leave a note to spare you the hours of frustration I spent trying to get it to work.

The command above launches the default WSL instance -- for me, this was a WSL2 instance. The WSL2 instance runs on a special/hidden virtual Switch, while the GNS3 VM on Hyper-V runs on the Default Switch. Communication between these two switches is restricted.

The solution is to install a WSL1 instance and specify that instance in the console application:

wsl --install -d Debian
wsl --set-version Debian 1

(use whichever distro you like, note that for Debian I had to sudo apt-get install telnet as well)

Then use this Distro to launch your telnet sessions: wsl.exe -d Debian telnet 10.77.77.2

(I don't know the significance of including or omitting ~ --exec, in my testing the results were the same)

My final GNS3 Console Command looked like this: wt.exe -w 0 --suppressApplicationTitle --title %d wsl.exe -d Debian telnet %h %p

erh-git avatar Sep 01 '22 15:09 erh-git

Now that terminal is the default on 22H2 this is a major issue. Please prioritise this issue

islandsins avatar Jan 13 '23 09:01 islandsins

Hello! Any news? i have the same problem when i try to manage my cisco switch via telnet or ssh... now terminal is the default...

YoruguaDEV avatar Jan 23 '23 12:01 YoruguaDEV

Nope. We'll make sure to update this thread when there is. In the meantime, might I recommend the Subscribe button? image That way you'll be notified of any updates to this thread, without needlessly pinging everyone on this thread ☺️

zadjii-msft avatar Jan 23 '23 12:01 zadjii-msft

Hi,

I confirm @shaunthorne 's workaround is working and is an acceptable solution in this case.

I've been trying to use Windows Terminal as the default console application for GNS3 network simulation software, and had the same buffering issues everyone is talking about. Using Plink works like a charm : wt -w0 split-pane --tabColor #C678DD --colorScheme "One Half Dark" --title %d --suppressApplicationTitle plink -telnet -P %p %h

thx

This solution is not satisfying because plink does not offer command history with arrow up and down.

the original issue has not been solved yet.

Blackers33 avatar Apr 09 '24 22:04 Blackers33