Add support for VT102 Insertion-Replace Mode (IRM) #2739

@j4james commented on GitHub (Jul 12, 2019):

I suspect this is because the Windows terminal doesn't yet support Insertion-Replacement Mode (IRM).

@j4james commented on GitHub (Jul 12, 2019): I suspect this is because the Windows terminal doesn't yet support [Insertion-Replacement Mode (IRM)](https://vt100.net/docs/vt102-ug/chapter5.html#S5.5.2.22).

claunia commented

@DHowett-MSFT commented on GitHub (Jul 20, 2019):

Interesting! Didn't know IRM was a thing. I'm going to repurpose this as a task to implement IRM.

Notes:

Insertion-Replacement Mode (IRM)

ESC  [   4   h
033 133 064 150

Set selects insert mode and turns INSERT on. New display characters move old display characters to the right. Characters moved past the right margin are lost.

ESC  [   4   l
033 133 064 154

Reset selects replace mode and turns INSERT off. New display characters replace old display characters at cursor position. The old character is erased.

@DHowett-MSFT commented on GitHub (Jul 20, 2019): Interesting! Didn't know IRM was a thing. I'm going to repurpose this as a task to implement IRM. Notes: ### Insertion-Replacement Mode (IRM) ``` ESC [ 4 h 033 133 064 150 ``` Set selects insert mode and turns INSERT on. New display characters move old display characters to the right. Characters moved past the right margin are lost. ``` ESC [ 4 l 033 133 064 154 ``` Reset selects replace mode and turns INSERT off. New display characters replace old display characters at cursor position. The old character is erased.

claunia commented

@egmontkob commented on GitHub (Oct 28, 2019):

Yet another symptom of the same bug:

Resize the window to 63 columns. Start mc (Midnight Commander) on Ubuntu, compiled against the S-Lang screen drawing library (as it's done in Ubuntu).

Expected: The bottom row should display 9 buttons, each of them being 2 characters for the function key number + 5 for the action. The rightmost should be <space>9Pu~Dn, reaching all the way to the very end.

Actual: <space>9Pu~D is printed with the expected colors, and the last column remains empty, showing the terminal's background color.

What the S-Lang library does is an ancient and obsolete hack for some terminals that don't have "pending wrap" (@j4james do you know more about them?), to print in the lower right corner without the cursor automatically wrapping to the next line and shifting everything up. It prints the intended last letter (n in this case) in the penultimate (62nd) column, and then using IRM, prints the penultimate letter (D) again in the penultimate (62nd) column, expecting it to push the previously printed n to the 63rd.

Even at bigger window sizes, such as the normal 80 columns, mc misses to paint the bottom right corner using some of its skins, e.g. F9 -> Options -> Appearance -> sand256 is one of these. For some mysterious reason, S-Lang decides to use different drawing method depending on some property of the skin. In this case, it repeats the aforementioned trick with space characters, whereas with most other themes, it just emits the escape sequence that wipes to the end.

This is a tiny inconsistency (almost-bug) somewhere in S-Lang, my wild guess is that it could be related to non-color attributes (in this case italic) being used there, but I don't think it's worth investigating S-Lang's behavior any further. Also, for the record: I couldn't reproduce the issue with mc compiled against ncurses, apparently it knows about "pending wrap" and knows that this hack is not necessary.

@egmontkob commented on GitHub (Oct 28, 2019): Yet another symptom of the same bug: Resize the window to 63 columns. Start `mc` (Midnight Commander) on Ubuntu, compiled against the S-Lang screen drawing library (as it's done in Ubuntu). Expected: The bottom row should display 9 buttons, each of them being 2 characters for the function key number + 5 for the action. The rightmost should be `<space>9Pu~Dn`, reaching all the way to the very end. Actual: `<space>9Pu~D` is printed with the expected colors, and the last column remains empty, showing the terminal's background color. What the S-Lang library does is an ancient and obsolete hack for some terminals that don't have "pending wrap" (@j4james do you know more about them?), to print in the lower right corner without the cursor automatically wrapping to the next line and shifting everything up. It prints the intended last letter (`n` in this case) in the penultimate (62nd) column, and then using IRM, prints the penultimate letter (`D`) again in the penultimate (62nd) column, expecting it to push the previously printed `n` to the 63rd. Even at bigger window sizes, such as the normal 80 columns, `mc` misses to paint the bottom right corner using _some_ of its skins, e.g. F9 -> Options -> Appearance -> sand256 is one of these. For some mysterious reason, S-Lang decides to use different drawing method depending on some property of the skin. In this case, it repeats the aforementioned trick with space characters, whereas with most other themes, it just emits the escape sequence that wipes to the end. This is a tiny inconsistency (almost-bug) somewhere in S-Lang, my wild guess is that it could be related to non-color attributes (in this case italic) being used there, but I don't think it's worth investigating S-Lang's behavior any further. Also, for the record: I couldn't reproduce the issue with `mc` compiled against ncurses, apparently it knows about "pending wrap" and knows that this hack is not necessary.

claunia commented

@j4james commented on GitHub (Oct 29, 2019):

What the S-Lang library does is an ancient and obsolete hack for some terminals that don't have "pending wrap" (@j4james do you know more about them?)

I know DOS and the original Windows shell didn't support "pending wrap", but then they wouldn't have supported IRM mode either. However, it wouldn't surprise me if there were other third-party terminal emulators for Windows that shared that wrapping behaviour, but were still able to handle IRM, so maybe that's the sort of thing that S-Lang is targetting.

By the way, IRM is on my TODO list (assuming nobody else takes it on first). It's just that we don't yet have a handler for ANSI modes, and the existing dispatch mechanism makes that a bit of a pain to add, so that was something I was hoping to address first. There are various other issues related to parameter handling (e.g. #2101 and possibly #942), and I wanted to make sure we had something that could satisfy all of those requirements if possible, so it's probably not going to be a quick fix.

@j4james commented on GitHub (Oct 29, 2019): > What the S-Lang library does is an ancient and obsolete hack for some terminals that don't have "pending wrap" (@j4james do you know more about them?) I know DOS and the original Windows shell didn't support "pending wrap", but then they wouldn't have supported `IRM` mode either. However, it wouldn't surprise me if there were other third-party terminal emulators for Windows that shared that wrapping behaviour, but were still able to handle `IRM`, so maybe that's the sort of thing that S-Lang is targetting. By the way, `IRM` is on my TODO list (assuming nobody else takes it on first). It's just that we don't yet have a handler for ANSI modes, and the existing dispatch mechanism makes that a bit of a pain to add, so that was something I was hoping to address first. There are various other issues related to parameter handling (e.g. #2101 and possibly #942), and I wanted to make sure we had something that could satisfy all of those requirements if possible, so it's probably not going to be a quick fix.

claunia commented

@zaphod77 commented on GitHub (Feb 1, 2020):

this is a a real issue. pico editor seems to use this when ran under emulated xterm. and the characters do not move to the right like they are supposed to.

still an issue as of this day.

@zaphod77 commented on GitHub (Feb 1, 2020): this is a a real issue. pico editor seems to use this when ran under emulated xterm. and the characters do not move to the right like they are supposed to. still an issue as of this day.

claunia commented

@henrikj242 commented on GitHub (Apr 9, 2020):

I'm also affected by this. Is there any known way to work around it?

@henrikj242 commented on GitHub (Apr 9, 2020): I'm also affected by this. Is there any known way to work around it?

claunia commented

@j4james commented on GitHub (Apr 9, 2020):

I was actually looking into this recently, and I think it's going to require some architectural decisions before we can consider implementing anything.

I'd initially thought that the AdaptDispatch class could handle the inserting prior to writing anything, by simply scrolling the line it was about to write into by the appropriate amount. But that assumes it knows how much space the text is going to take (which it doesn't), and if the text is going to wrap onto another line, then potentially handle inserting on later lines (which may not even exist yet if vertical scrolling is required).

As things currently stand, I don't think this is possible. So either the inserting must be handled in the PrintString implementation itself (which is essentially the WriteCharsLegacy function that we don't want to touch). Or the AdaptDispatch class needs to take over the majority of the text layout, and have PrintString be a very basic operation that only writes to a single line (no inserting, wrapping, scrolling, or margin checks).

Considering the additional complications that are going to be introduced to the layout as we expand the VT functionality, I think the latter option may well be the best long term approach. But that is going to require some additional APIs, e.g. to query how much space a string of text will occupy and/or where it would be clipped.

@j4james commented on GitHub (Apr 9, 2020): I was actually looking into this recently, and I think it's going to require some architectural decisions before we can consider implementing anything. I'd initially thought that the `AdaptDispatch` class could handle the inserting prior to writing anything, by simply scrolling the line it was about to write into by the appropriate amount. But that assumes it knows how much space the text is going to take (which it doesn't), and if the text is going to wrap onto another line, then potentially handle inserting on later lines (which may not even exist yet if vertical scrolling is required). As things currently stand, I don't think this is possible. So either the inserting must be handled in the `PrintString` implementation itself (which is essentially the `WriteCharsLegacy` function that we don't want to touch). Or the `AdaptDispatch` class needs to take over the majority of the text layout, and have `PrintString` be a very basic operation that only writes to a single line (no inserting, wrapping, scrolling, or margin checks). Considering the additional complications that are going to be introduced to the layout as we expand the VT functionality, I think the latter option may well be the best long term approach. But that is going to require some additional APIs, e.g. to query how much space a string of text will occupy and/or where it would be clipped.

claunia commented

@philkernick commented on GitHub (Jul 19, 2020):

I also have the same problem, but I have a workaround.

FreeBSD uses termcap (rather than terminfo) and the termcap entries for xterm include the 'im' and 'ei' capabilities which invoke the VT102 IRM. In the Linux terminfo database, these capabilities are not implemented.

The workaround is to create a .termcap file in your home directory with this one entry in it:
xterm-256color:mi@:IC=\E[%d@:ei@:ic=\E[@:im@:tc=xterm-new:

This will use this instead for the xterm-256color terminal (which is what Windows Terminal is), and delete the 'im' and 'ei' capabilities.

Until the IRM capabilities are implemented, this works perfectly.

@philkernick commented on GitHub (Jul 19, 2020): I also have the same problem, but I have a workaround. FreeBSD uses termcap (rather than terminfo) and the termcap entries for xterm include the 'im' and 'ei' capabilities which invoke the VT102 IRM. In the Linux terminfo database, these capabilities are not implemented. The workaround is to create a .termcap file in your home directory with this one entry in it: `xterm-256color:mi@:IC=\E[%d@:ei@:ic=\E[@:im@:tc=xterm-new:` This will use this instead for the xterm-256color terminal (which is what Windows Terminal is), and delete the 'im' and 'ei' capabilities. Until the IRM capabilities are implemented, this works perfectly.

claunia commented

@DHowett commented on GitHub (Jul 26, 2020):

It's wild how IRM works with line wrapping in xterm (351). Text is pushed off the right margin, as expected, but when the inserted region is wider than will fit it wraps and pushes text on the next line to the right.

This is a terribly specific feature. I wonder why it was introduced!

@DHowett commented on GitHub (Jul 26, 2020): It's wild how IRM works with line wrapping in xterm (351). Text is pushed off the right margin, as expected, but when the inserted region is wider than will fit _it_ wraps and pushes text on the _next_ line to the right. This is a terribly specific feature. I wonder why it was introduced!

claunia commented

@vixie commented on GitHub (Oct 6, 2020):

no version of xterm has ever not supported IRM. if you're not going to implement it, please identify yourself as a VT100 instead of xterm256-color. the pending-wrap thing is a side show, don't worry about it. just please make :ei=\E[4l: and :im=\E[4h: work. i've gone back to konsole as a result of this bug.

@vixie commented on GitHub (Oct 6, 2020): no version of xterm has ever not supported IRM. if you're not going to implement it, please identify yourself as a VT100 instead of xterm256-color. the pending-wrap thing is a side show, don't worry about it. just please make :ei=\E[4l: and :im=\E[4h: work. i've gone back to konsole as a result of this bug.

claunia commented

@zaphod77 commented on GitHub (Oct 6, 2020):

I have to use putty because of this STILL, even though putty doesn't have perfect xterm emulation either. For those of you who can't seem to reproduce this, your pico is actually nano, which has a workaround for this bug.

If you actually use the pico text editor, you can very easily see the behavior. it's the simplest test case.

@zaphod77 commented on GitHub (Oct 6, 2020): I have to use putty because of this STILL, even though putty doesn't have perfect xterm emulation either. For those of you who can't seem to reproduce this, your pico is actually nano, which has a workaround for this bug. If you actually use the pico text editor, you can very easily see the behavior. it's the simplest test case.

claunia commented

@mreymann commented on GitHub (Oct 8, 2020):

The workaround is to create a .termcap file in your home directory with this one entry in it:
xterm-256color:mi@:IC=\E[%d@:ei@:ic=\E[@:im@:tc=xterm-new:
Until the IRM capabilities are implemented, this works perfectly.

Thanks, your workaround fixes some weird behaviour when connecting to FreeBSD boxes. Waiting for a real fix ;-)

@mreymann commented on GitHub (Oct 8, 2020): > The workaround is to create a .termcap file in your home directory with this one entry in it: > `xterm-256color:mi@:IC=\E[%d@:ei@:ic=\E[@:im@:tc=xterm-new:` > Until the IRM capabilities are implemented, this works perfectly. Thanks, your workaround fixes some weird behaviour when connecting to FreeBSD boxes. Waiting for a real fix ;-)

claunia commented

@vixie commented on GitHub (Oct 8, 2020):

Marc Reymann writes:

...

Thanks, your workaround fixes some weird behaviour when connecting to
FreeBSD boxes. Waiting for a real fix ;-)

freebsd is not the only place this matters. other systems also expect that
if the offered terminal type is xterm256-color, then IRM will work. my
workaround is to use TERM=vt100, which means, my workaround is to use
konsole instead.

@vixie commented on GitHub (Oct 8, 2020): Marc Reymann writes: >> ... > > Thanks, your workaround fixes some weird behaviour when connecting to > FreeBSD boxes. Waiting for a real fix ;-) freebsd is not the only place this matters. other systems also expect that if the offered terminal type is xterm256-color, then IRM will work. my workaround is to use TERM=vt100, which means, my workaround is to use konsole instead.

claunia commented

@zatarain commented on GitHub (Nov 29, 2020):

Great!! I was dealing with this bug since April, it was really annoying. I just apply the workaround with xterm-clear:te=\E[?1049l:ti=\E[?1049h:mi@:IC=\E[%d@:ei@:ic=\E[@:im@:tc=xterm-new: and it worked!! I hope Microsoft implements the real fix soon!!

@zatarain commented on GitHub (Nov 29, 2020): Great!! I was dealing with this bug since April, it was really annoying. I just apply the workaround with `xterm-clear:te=\E[?1049l:ti=\E[?1049h:mi@:IC=\E[%d@:ei@:ic=\E[@:im@:tc=xterm-new:` and it worked!! I hope Microsoft implements the real fix soon!!

claunia commented

@DHowett commented on GitHub (Nov 29, 2020):

I'm taking a crack at this.

It looks like we don't even have SM/RM, so there's a lot of plumbing to do.

@DHowett commented on GitHub (Nov 29, 2020): I'm taking a crack at this. ![irm](https://user-images.githubusercontent.com/189190/100530871-4e233c00-31ac-11eb-9ec6-bebdc3447395.gif) It looks like we don't even have `SM`/`RM`, so there's a lot of plumbing to do.

claunia commented

@DHowett commented on GitHub (Nov 29, 2020):

@j4james the approach I've gone with -- which is of course subject to discussion and eventual change 😄 -- is to make TextBuffer do an inserting write at the cursor position. I've not made any architectural changes to Adapt or change whose job it is to do text layout. I tested gnome-terminal here & found that they don't do any re-wrapping, even if the line was emitted wrapped. Insert mode there impacts only the physical display & not the logical paragraph/wrap state.

@DHowett commented on GitHub (Nov 29, 2020): @j4james the approach I've gone with -- which is of course subject to discussion and eventual change :smile: -- is to make TextBuffer do an inserting write at the cursor position. I've not made any architectural changes to Adapt or change whose job it is to do text layout. I tested gnome-terminal here & found that they don't do any re-wrapping, _even if_ the line was emitted wrapped. Insert mode there impacts only the physical display & not the logical paragraph/wrap state.

claunia commented

@vixie commented on GitHub (Nov 29, 2020):

happy to review or test.

@vixie commented on GitHub (Nov 29, 2020): happy to review or test.

claunia commented

@j4james commented on GitHub (Nov 29, 2020):

make TextBuffer do an inserting write at the cursor position.

Yeah, but where are you doing that? In the WriteCharsLegacy implementation? And if so, that assumedly requires another OutputMode flag, or at least another WC_* flag. I just assumed we wouldn't want to be introducing more complexity there?

I was starting to think maybe now was a good time to take on #780, and incorporate the IRM functionality there. That seemed easier than worrying about how this would impact the legacy code. But maybe I'm overthinking things and you've got a simpler solution that I'm just not seeing.

It looks like we don't even have SM/RM, so there's a lot of plumbing to do.

Yeah, that's why I wanted to get #7799 out the way first. It should at least be easer to extend the framework now than it was back then.

@j4james commented on GitHub (Nov 29, 2020): > make TextBuffer do an inserting write at the cursor position. Yeah, but where are you doing that? In the `WriteCharsLegacy` implementation? And if so, that assumedly requires another `OutputMode` flag, or at least another `WC_*` flag. I just assumed we wouldn't want to be introducing more complexity there? I was starting to think maybe now was a good time to take on #780, and incorporate the IRM functionality there. That seemed easier than worrying about how this would impact the legacy code. But maybe I'm overthinking things and you've got a simpler solution that I'm just not seeing. > It looks like we don't even have `SM`/`RM`, so there's a lot of plumbing to do. Yeah, that's why I wanted to get #7799 out the way first. It should at least be easer to extend the framework now than it was back then.

claunia commented

@zatarain commented on GitHub (Nov 29, 2020):

It would be nice if you add some spaces to see how it behaves on multi word lines.

I'm taking a crack at this.

It looks like we don't even have SM/RM, so there's a lot of plumbing to do.

@zatarain commented on GitHub (Nov 29, 2020): It would be nice if you add some spaces to see how it behaves on multi word lines. > I'm taking a crack at this. > > ![irm](https://user-images.githubusercontent.com/189190/100530871-4e233c00-31ac-11eb-9ec6-bebdc3447395.gif) > > It looks like we don't even have `SM`/`RM`, so there's a lot of plumbing to do.

claunia commented

@DHowett commented on GitHub (Nov 29, 2020):

@j4james oh, right. Sorry to be inexact. Since all of the at-cursor writes coming out of WriteCharsLegacy (and any other source in conhost; see _stream.cpp:536 for the only instance I could find) go through SCREEN_INFORMATION::Write(OutputCellIterator), I put IRM determination in SCREEN_INFORMATION and kept it out of WCL. That keeps it away from any modes, control character handling, knowledge of backup/line wrapping state, etc.

Every other Write uses a coordinate target, but perhaps it would be prudent to rename this one to WriteAtCursor.

Does that seem a reasonable place?

@DHowett commented on GitHub (Nov 29, 2020): @j4james oh, right. Sorry to be inexact. Since all of the at-cursor writes coming out of `WriteCharsLegacy` (and any other source in conhost; see `_stream.cpp:536` for the only instance I could find) go through `SCREEN_INFORMATION::Write(OutputCellIterator)`, I put IRM determination in `SCREEN_INFORMATION` and kept it out of WCL. That keeps it away from any modes, control character handling, knowledge of backup/line wrapping state, etc. Every other Write uses a coordinate target, but perhaps it would be prudent to rename this one to `WriteAtCursor`. Does that seem a reasonable place?

claunia commented

@j4james commented on GitHub (Nov 29, 2020):

OK that's brilliant. That's so much simpler than I was expecting. I can't see any reason why that wouldn't work. :shipit:

@j4james commented on GitHub (Nov 29, 2020): OK that's brilliant. That's so much simpler than I was expecting. I can't see any reason why that wouldn't work. :shipit:

claunia commented

@DHowett commented on GitHub (Jan 2, 2021):

Happy New Year! Draft PR up in #8689.

@DHowett commented on GitHub (Jan 2, 2021): Happy New Year! Draft PR up in #8689.

claunia commented

@zaphod77 commented on GitHub (Sep 9, 2021):

Please ignore results in Gnome Terminal, unless they can be reproduced under real XTerm.

IRM is designed for the case of a text editor with autowrap turned off. This saves bandwidth. The test case animated graphic is not a real world scenario, though it is what sending the raw characters to the terminal would do.

@zaphod77 commented on GitHub (Sep 9, 2021): Please ignore results in Gnome Terminal, unless they can be reproduced under real XTerm. IRM is designed for the case of a text editor with autowrap turned off. This saves bandwidth. The test case animated graphic is not a real world scenario, though it is what sending the raw characters to the terminal would do.

claunia commented

@kingma-sbw commented on GitHub (Jul 1, 2022):

Connecting to a (Arch)Linux box has the problem. No IRM. If I isseu export TERM=vt100 vi behaves as designed. It would be great to include this as setting. Connecting with PuTTY works fine and offers a variety of settings:

@kingma-sbw commented on GitHub (Jul 1, 2022): Connecting to a (Arch)Linux box has the problem. No IRM. If I isseu ```export TERM=vt100``` vi behaves as designed. It would be great to include this as setting. Connecting with PuTTY works fine and offers a variety of settings: ![image](https://user-images.githubusercontent.com/50140049/176836434-c5b7d076-c83f-42f5-a556-d791824ee63d.png)

claunia commented

@Forge36 commented on GitHub (Jul 22, 2022):

Is this the root cause of cursor mode not changing?
IE: in CMD

vs

Or should this be considered a new issue?

@Forge36 commented on GitHub (Jul 22, 2022): Is this the root cause of cursor mode not changing? IE: in CMD ![image](https://user-images.githubusercontent.com/30872404/180514433-56ca642f-884d-4867-ab34-8e4221f0c908.png) vs ![image](https://user-images.githubusercontent.com/30872404/180514396-5271741a-fb7b-426b-81dc-227030077483.png) Or should this be considered a new issue?

claunia commented

@DHowett commented on GitHub (Jul 22, 2022):

The feature here--IRM--is unrelated to any CMD features or console applications that use the "Windows-style" cooked input feature (Python, PowerShell without PSReadline, Command Prompt).

@DHowett commented on GitHub (Jul 22, 2022): The feature here--IRM--is unrelated to any CMD features or console applications that use the "Windows-style" cooked input feature (Python, PowerShell without PSReadline, Command Prompt).

claunia commented

@kingma-sbw commented on GitHub (Jul 29, 2022):

I'm also affected by this. Is there any known way to work around it?

Yes it is setting the TERM variable to VT100

export TERM=vt100

@kingma-sbw commented on GitHub (Jul 29, 2022): > I'm also affected by this. Is there any known way to work around it? Yes it is setting the TERM variable to VT100 ``` export TERM=vt100 ```

claunia commented

@davhae commented on GitHub (Sep 26, 2022):

I'm also affected by this. Is there any known way to work around it?

I am just using tmux to prevent insert mode before the last space in a command. The Issue only happens to me when editing a command from the history.

export TERM=vt100 did not change this behaviour.

@davhae commented on GitHub (Sep 26, 2022): > I'm also affected by this. Is there any known way to work around it? I am just using tmux to prevent insert mode before the last space in a command. The Issue only happens to me when editing a command from the history. `export TERM=vt100` did not change this behaviour.

claunia commented

@Anutrix commented on GitHub (Dec 11, 2022):

Can't SSH into a lot of lab/course(from online course sites) VMs because of this.

Any workarounds for this?
export TERM=vt100 didn't work.

@Anutrix commented on GitHub (Dec 11, 2022): Can't SSH into a lot of lab/course(from online course sites) VMs because of this. Any workarounds for this? `export TERM=vt100` didn't work.

claunia commented

@vixie commented on GitHub (Dec 11, 2022):

Numan Zaheer Ahmed wrote on 2022-12-11 15:32:

Can't SSH into a lot of lab/course(from Coursera, Udemy, etc.) VMs
because of this.

Any workarounds for this?

don't use microsoft's terminal emulator. stick with securecrt, or
install linux or freebsd inside "hyper-v" and run your terminal sessions
inside the client VM. neither microsoft's "terminal" or "ssh" are ready
for prime time.

|export TERM=vt100| did't work.

i should have been clearer. "export TERM=vt100" is what you do on the
remote system after you log in. the sshd that launches your shell there
is going to pass the TERM variable it gets from the ssh session. i have
not figured out how to get this to be passes as "vt100" by the invoking
ssh inside the powershell or command CLI on the initiating side. but if
i override it on the remote shell, everything i invoke there hears that
my terminal type is "vt100".

i guess coursera and udemy don't have shells and the TERM variable their
sshd gets from your ssh has to be correct? sorry about my ignorance, i
don't use ssh that way.

--
P Vixie

@vixie commented on GitHub (Dec 11, 2022): Numan Zaheer Ahmed wrote on 2022-12-11 15:32: > Can't SSH into a lot of lab/course(from Coursera, Udemy, etc.) VMs > because of this. > > Any workarounds for this? don't use microsoft's terminal emulator. stick with securecrt, or install linux or freebsd inside "hyper-v" and run your terminal sessions inside the client VM. neither microsoft's "terminal" or "ssh" are ready for prime time. > |export TERM=vt100| did't work. i should have been clearer. "export TERM=vt100" is what you do on the remote system after you log in. the sshd that launches your shell there is going to pass the TERM variable it gets from the ssh session. i have not figured out how to get this to be passes as "vt100" by the invoking ssh inside the powershell or command CLI on the initiating side. but if i override it on the remote shell, everything i invoke there hears that my terminal type is "vt100". i guess coursera and udemy don't have shells and the TERM variable their sshd gets from your ssh has to be correct? sorry about my ignorance, i don't use ssh that way. -- P Vixie

claunia commented

@Anutrix commented on GitHub (Dec 11, 2022):

don't use microsoft's terminal emulator. stick with securecrt, or install linux or freebsd inside "hyper-v" and run your terminal sessions inside the client VM. neither microsoft's "terminal" or "ssh" are ready for prime time.

It's ssh on WSL2(which is basically a VM now) so not Microsoft ssh. As for windows terminal, not using it is not solution. Good alternative console emulators/terminals are hard to find on Windows.

|export TERM=vt100| did't work.
i should have been clearer. "export TERM=vt100" is what you do on the remote system after you log in. the sshd that launches your shell there is going to pass the TERM variable it gets from the ssh session. i have not figured out how to get this to be passes as "vt100" by the invoking ssh inside the powershell or command CLI on the initiating side. but if i override it on the remote shell, everything i invoke there hears that my terminal type is "vt100". i guess coursera and udemy don't have shells and the TERM variable their sshd gets from your ssh has to be correct? sorry about my ignorance, i don't use ssh that way.
…
-- P Vixie

I ran the command inside the remote system after I logged in. Still didn't work.
Thx anyways. I should have mentioned where I ran it.

@Anutrix commented on GitHub (Dec 11, 2022): > don't use microsoft's terminal emulator. stick with securecrt, or install linux or freebsd inside "hyper-v" and run your terminal sessions inside the client VM. neither microsoft's "terminal" or "ssh" are ready for prime time. It's ssh on WSL2(which is basically a VM now) so not Microsoft ssh. As for windows terminal, not using it is not solution. Good alternative console emulators/terminals are hard to find on Windows. > |export TERM=vt100| did't work. > i should have been clearer. "export TERM=vt100" is what you do on the remote system after you log in. the sshd that launches your shell there is going to pass the TERM variable it gets from the ssh session. i have not figured out how to get this to be passes as "vt100" by the invoking ssh inside the powershell or command CLI on the initiating side. but if i override it on the remote shell, everything i invoke there hears that my terminal type is "vt100". i guess coursera and udemy don't have shells and the TERM variable their sshd gets from your ssh has to be correct? sorry about my ignorance, i don't use ssh that way. > […](#) > -- P Vixie I ran the command inside the remote system after I logged in. Still didn't work. Thx anyways. I should have mentioned where I ran it.

claunia commented

@vixie commented on GitHub (Dec 12, 2022):

Numan Zaheer Ahmed wrote on 2022-12-11 15:58:

...
It's ssh on WSL2(which is basically a VM now) so not Microsoft ssh. As
for windows terminal, not using it is not solution. Good alternative
console emulators/terminals are hard to find on Windows.

if you're using WSL2 you might try mintty which claims to run there and
is based on putty which has working xterm escape sequences like IRM.

I ran the command inside the remote system after I logged in. Still
didn't work. ... Thx anyways. I should have mentioned where I ran it.

can you say more about what doesn't work and under what conditions? i
find that once i set TERM=vt100 (or TERM=vt220) on the remote shell, all
the text editors and screen oriented utilities stop trying to use IRM,
and thus work passably well with Windows Terminal.

i'm using Windows Terminal Preview but i just tested and it's the same
for Windows Terminal as shipped from the microsoft store.

--
P Vixie

@vixie commented on GitHub (Dec 12, 2022): Numan Zaheer Ahmed wrote on 2022-12-11 15:58: > ... > > It's ssh on WSL2(which is basically a VM now) so not Microsoft ssh. As > for windows terminal, not using it is not solution. Good alternative > console emulators/terminals are hard to find on Windows. if you're using WSL2 you might try mintty which claims to run there and is based on putty which has working xterm escape sequences like IRM. > I ran the command inside the remote system after I logged in. Still > didn't work. ... Thx anyways. I should have mentioned where I ran it. can you say more about what doesn't work and under what conditions? i find that once i set TERM=vt100 (or TERM=vt220) on the remote shell, all the text editors and screen oriented utilities stop trying to use IRM, and thus work passably well with Windows Terminal. i'm using Windows Terminal Preview but i just tested and it's the same for Windows Terminal as shipped from the microsoft store. -- P Vixie

claunia commented

@Anutrix commented on GitHub (Dec 12, 2022):

if you're using WSL2 you might try mintty which claims to run there and is based on putty which has working xterm escape sequences like IRM.

Recent release of mintty binary seems hard to find(and am trying to avoid MSYS2). I will try wsltty from the developer of mintty instead.
Update: Same issue in mintty. Starting to think it might be WSL/Windows issue.
Additionally, mintty is used in Git Bash terminal where WSL doesn't seem to work anymore. Gives no output when I try to start WSL.

I ran the command inside the remote system after I logged in. Still didn't work. ... Thx anyways. I should have mentioned where I ran it.
can you say more about what doesn't work and under what conditions?

I just SSH into the remote shell. I press and hold a character(let's say 'a' or just paste a long string). It overwrites the first character after end of line is reached instead of moving to next line.

@Anutrix commented on GitHub (Dec 12, 2022): > if you're using WSL2 you might try mintty which claims to run there and is based on putty which has working xterm escape sequences like IRM. Recent release of mintty binary seems hard to find(and am trying to avoid MSYS2). I will try [wsltty](https://github.com/mintty/wsltty) from the developer of mintty instead. **Update:** Same issue in mintty. Starting to think it might be WSL/Windows issue. Additionally, mintty is used in Git Bash terminal where WSL doesn't seem to work anymore. Gives no output when I try to start WSL. > I ran the command inside the remote system after I logged in. Still didn't work. ... Thx anyways. I should have mentioned where I ran it. > can you say more about what doesn't work and under what conditions? I just SSH into the remote shell. I press and hold a character(let's say 'a' or just paste a long string). It overwrites the first character after end of line is reached instead of moving to next line.

claunia commented

@vixie commented on GitHub (Dec 12, 2022):

depending on the remote shell choice, it may not notice that you've
changed the TERM variable. more reliably, the commands you run from that
shell will inherit the modified environment (TERM=vt220 or whatever). to
be sure you're getting shell-level behaviour effects warranted by your
new terminal type, do something like this:

export TERM=vt220
exec bash

or, if you're like me using csh:

setenv TERM vt220
exec tcsh

or if you're using a modern mac/os ssh server-side:

export TERM=vt220
exec zsh

and so on. but your best test is still:

export TERM=vt220
emacs -nw $somefile

if your TERM indicates IRM and your terminal doesn't implement IRM then
emacs (among other utilities) will not be able to keep your screen updated.

Numan Zaheer Ahmed wrote on 2022-12-12 13:04:

@vixie commented on GitHub (Dec 12, 2022): depending on the remote shell choice, it may not notice that you've changed the TERM variable. more reliably, the commands you run from that shell will inherit the modified environment (TERM=vt220 or whatever). to be sure you're getting shell-level behaviour effects warranted by your new terminal type, do something like this: export TERM=vt220 exec bash or, if you're like me using csh: setenv TERM vt220 exec tcsh or if you're using a modern mac/os ssh server-side: export TERM=vt220 exec zsh and so on. but your best test is still: export TERM=vt220 emacs -nw $somefile if your TERM indicates IRM and your terminal doesn't implement IRM then emacs (among other utilities) will not be able to keep your screen updated. Numan Zaheer Ahmed wrote on 2022-12-12 13:04:

claunia commented

@Anutrix commented on GitHub (Dec 12, 2022):

export TERM=vt220
exec bash

It works fine inside new shell but I lose UI benefits as it goes to a basic terminal.

and so on. but your best test is still:
export TERM=vt220
emacs -nw $somefile
if your TERM indicates IRM and your terminal doesn't implement IRM then
emacs (among other utilities) will not be able to keep your screen updated.

The remote shell is a limited environment without vim, nano, emacs.
There might be a problem with the shell itself. I'll try check with their support.

Update: Sry about all that. There PS1 seems to be broken/bad on the remote shell. So ignore my earlier troubles. Wasn't related to VT102 IRM. Marking my messages as off-topic.

@Anutrix commented on GitHub (Dec 12, 2022): > export TERM=vt220 > exec bash ![image](https://user-images.githubusercontent.com/11459028/207158232-f1b253ca-4bb6-481e-9a49-b15647b4cbc6.png) It works fine inside new shell but I lose UI benefits as it goes to a basic terminal. > and so on. but your best test is still: > export TERM=vt220 > emacs -nw $somefile > if your TERM indicates IRM and your terminal doesn't implement IRM then > emacs (among other utilities) will not be able to keep your screen updated. The remote shell is a limited environment without vim, nano, emacs. There might be a problem with the shell itself. I'll try check with their support. **Update:** Sry about all that. There PS1 seems to be broken/bad on the remote shell. So ignore my earlier troubles. Wasn't related to VT102 IRM. Marking my messages as off-topic.

claunia commented

@dmiller423 commented on GitHub (Dec 24, 2022):

This is still open 3&&1/2yrs later?
@lhecker I see you've been assigned this 2weeks ago, is it actually something in progress finally?

@dmiller423 commented on GitHub (Dec 24, 2022): This is still open 3&&1/2yrs later? @lhecker I see you've been assigned this 2weeks ago, is it actually something in progress finally?

claunia commented

@zaphod77 commented on GitHub (Dec 24, 2022):

The main issue here is UnicodeStorage, which is not very friendly to trying to do this. #8000 needs to finish first, and then this can be solved.

@zaphod77 commented on GitHub (Dec 24, 2022): The main issue here is UnicodeStorage, which is not very friendly to trying to do this. #8000 needs to finish first, and then this can be solved.

claunia commented