xterm emulation still buggy.

[zaphod77]

Please answer the following

If it is a terminal issue then please go through wiki https://github.com/PowerShell/Win32-OpenSSH/wiki/TTY-PTY-support-in-Windows-OpenSSH Yes, I did.

"OpenSSH for Windows" version OpenSSH_for_Windows_7.6p1, LibreSSL 2.6.4

Server OperatingSystem Any Linux.

Client OperatingSystem Microsoft Windows [Version 10.0.17134.285]

What is failing Faulty xterm emulation

Expected output text should move over when you type in pico text editor.

Actual output typing overwrites on screen, when it should be visibly inserting. putty's xterm emulation is correct.

this is impossible to screenshot, but you can easily test for yourself.

[zaphod77]

anyone? until this is fixed, ssh.exe is useless to me if the xterm emulation is bad enough that a simple lightweight text editor does not function.

[marekr]

Same issues here :/

It used to be buggy with Nano where the first character of the document was offset/hidden. Now the character offset bug is gone but if you page up and down enough in Nano, it eventually dissociates content from scroll in a weird overlapping mess. Vim/Vi occasionally go nutty now too when they were previously fine.

[zaphod77]

still busted for me. is there a newer version to test?

i still have the same version i posted in the initial test.

okay found a 7.9p1 and tried it. same issue. pico does not move the characters to the right when inserting at all. works fine in the shell prompt itself. putty works fine.

note that the WSL binary for ssh has the same terminal emulation issues.

[WSLUser]

WSL ssh has nothing to do with this project. That's the official ssh source that win32 has forked from. Nothing wrong with it. Problem was the Windows Console itself. On Windows 7 though xterm emulation is extremely poor. I'm unable to use vim or nano and lines like to disappear on me, sometimes entering clear a bunch of times or pressing enter a few times is needed to get a regular bash prompt to appear. when you attempt to type commands without the prompt, not all the characters are visible and tab completion becomes more painful since you can't read what was input and just have to trust it is what you wanted to be.

[zaphod77]

It has everything to do with this port. it needs to figure out how to translate xterm codes to something that works in the cmd or powershell window. i've even tried stuff like conemu, and it still no help. Only thing that's actually worked for me is standalone ssh programs with their own terminal emulation.

Are you saying this is an impossible task, and that what's actually needed is a command prompt replacement that has full color xterm capabilities?

[zaphod77]

okay all the terminal issues go away when using CMDER (clink+conemu) conemu alone does NOT solve this.

if you install and run cmder, and ssh from that, it Just Works(tm). now if i can just figure out how to replace the default console window...

[WSLUser]

CMDer also has mintty from msys (the cygwin version is better). Mintty uses winpty and replaces the default console. That's why it probably works. Mintty supports the necessary xterm sequences and could use the ssh port from Cygwin or the win32 (or even the WSL ssh). They really should focus on making Win 7 and 8 better with xterm emulation. Just because the native Console has barely any xterm support on those versions of Windows doesn't mean they can't make it work. If Mintty and other projects can do it then so can the win32-ssh team. They could even integrate Mintty as a backend for terminal emulation if they wanted.

[zaphod77]

okay set TERM=ansi reliably functions when using win32-ssh on windows 10.

Color works, pico works, pretty much everything that uses ncurses works as far as I know.

for windows 7 and 8, also should probably use

set SSH_TERM_CONHOST_PARSER=0 along with set TERM=ansi

This should give a decent experience.

No idea what to do about XP. some people say you can load ansi.sys, but that doesn't seem reliable. Presumably the build in support might work, but i think it requires conhost, which doesn't exist on xp. so think xp people are out of luck unless they can get ansi in their command prompt, in which case win32-ssh can pass thru.

Suggestion. try to detect windows 10 conhost vs windows7. If 10 is detected, temporarily set term to ansi until xterm-256 emulation is fixed. Once this actually gets fixed, and the torture tests pass, remove this hack.

If windows 7-8 conhost.exe is detected, auto disable the conhost parser(cuz only windows 10s will work), and set TERM=ansi if it's undefined

(these are never gonna get fixed)

if it is NOT being run under either of those, then use current behavior.

alternatively implement a full xterm parser that works under the as many default windows32 terminals as possible.

[zaphod77]

and no, cmdr doesn't seem to use mintty unless you tell it to. but it still gets the xterm codes right enough to not break pico.

but it doesn't allow mouse capture the way a real xterm would, say if you ran tmux with mouse support on.

gah. time to bitch about conhost.exe not having full xterm support...

[maertendMSFT]

Please try this is the latest release. If it persists, then we will follow-up with the console team.

[zaphod77]

still persists.

C:\Users\zapho\Downloads>ssh -V OpenSSH_for_Windows_8.1p1, LibreSSL 2.6.5

C:\Users\zapho\Downloads>

insert does not work inside pico.

The problem appears to be an unimplemented escape code. i'm trying to work out what it is.

[bagajjal]

@zaphod77 - We have full xterm support on windows 10. For downlevel OS like Win7/Win8, we have VT100 implementation. We don't support XP.

I don't see any issues with pico using ssh client running on windows 10. Characters move right when I insert new characters. Character move left when I delete characters.

[bagajjal]

@zaphod77 - I wonder how you got LibreSSL 2.6.5 with v8.1. It should be 2.9.2.1. https://github.com/PowerShell/Win32-OpenSSH/releases/tag/v8.1.0.0p1-Beta

[zaphod77]

@bagajjal this IS windows 10.

odd it happened for me. and happens every time i try. it's done this since day 1.

there must be something odd about your setup. i tried on another windows 10 machine. same results with that release.

[zaphod77]

what is your version of conhost.exe? mine is 10.0.18362.1

is there a newer one?

[WSLUser]

is there a newer one?

Yep, if you build from source. Try using Windows Terminal, which includes the newest bits of the console and conpty.

[bagajjal]

Yes. I am on Microsoft Windows [Version 10.0.19041.208].

[zaphod77]

i just installed ver 2004, and now my conhost is 10.0.19041.153

this STILL happens!

it happens with cmd, it happens with powershell, and it happens with windows terminal.

on every computer i try.

by default pico is in insert mode.

this means when you type on a line that has text it should push the text over. it does not it overtypes, while internally the text is pushed over.

Here is exactly how to reproduce. 0) touch test.txt 1) pico test.txt 2) type a line of text. 3) press enter until it scrolls off the screen. 4) go back up and type new text. you will see the text overwriting. 5) scroll the line off the top of the screen and return. the overwritten text will be there.

this has happened from day one, and it still happens. same happens with everything else i've tried except CMDer, which doesn't support mouse capture properly for tmux.

I just want a native windows xterm.exe which can load cmd or powershell. why is this so hard???

[bagajjal]

@zaphod77 - I couldn't repro this. Did I miss anything?

Please see the attached gif

[zaphod77]

I see the issue. you are using nano, which works, but aliased to pico.

try with actual pico (that says pico at the top)

then you will reproduce the problem.

type "pico --version" to see if you really have pico.

zaphod@eunich:~$ pico --version Argument Error: unknown flag "-" Pico 5.05

zaphod@eunich:~$ nano --version GNU nano version 2.3.1 (compiled 13:55:49, Jun 20 2012) (C) 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009 Free Software Foundation, Inc. Email: nano@nano-editor.org Web: http://www.nano-editor.org/ Compiled options: --disable-wrapping-as-root --enable-color --enable-extra --enable-multibuffer --enable-nanorc --enable-utf8

to get actual pico, install alpine email package. 5.05 is the latest version of pico.

[zaphod77]

Why is this closed? it's still not fixed. real pico text editor does not work. This is to do with insertion replace mode, which is still not supported, which real xterm DOES support.

[bagajjal]

I talked to @DHowett-MSFT (microsoft console team). This is duplicate of https://github.com/microsoft/terminal/issues/1947.

[bagajjal]

The issue is not in win32-openssh but is in console code.

[zaphod77]

all i want is a simple terminal emulator that's free and passes VTTEST on win32. is that so hard?!?!

and i can't even comment on that other issue.

will someone who can point them at https://invisible-island.net/vttest/#download ? :)

[bagajjal]

@zaphod77 - Request you to follow up with the console team https://github.com/microsoft/terminal/issues/1947

[DHowett]

@zaphod77 If you have something to add to that discussion that is not (paraphrased) "you are incompetent, how hard could it be for you to do this," I would welcome you to comment there. However, I locked the issue before I asked @bagajjal to tell you that it was a duplicate because I wanted to give you some time to calm down. Do you have a specific insight about IRM that would help us implement it, such that I can unlock it?

[zaphod77]

I was not trying to question the competence of the ms team. It's just annoying in general when nobody on the entire internet can seem to do a simple request. my only real remaining insight is that that VTTEST program can be compiled and ran on WSL, and be used to test the terminal emulation for the new console. (there is a section for testing xterm emulation now)

[DHowett]

We love vttest! There's a whole lot of stuff in there and while we do eventually want to get it all, we have to prioritize those things so that we hit the peak of "things that are used commonly" and "things that fit well within our architecture" without causing our engineers to burn out on doing VT work.

It can be pretty unforgiving sometimes. IRM is one I'm personally interested in working on (even though as the team lead I shouldn't be writing code 🙂) because I want bash on FreeBSD to work properly; it also uses IRM and acts pretty crazy when it doesn't work.

In truth, our architecture doesn't support insertion very easily, because our text buffer was originally designed to work like the old VGA text mode. It's getting better, but only slowly.

[DHowett]

(Speaking of: I’ve unlocked the issue over on Terminal. Thanks/sorry!)