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

console doesn't support xterm-256color's "Esc E" for newline #14603

Closed
hsenag opened this issue Dec 25, 2022 · 3 comments
Closed

console doesn't support xterm-256color's "Esc E" for newline #14603

hsenag opened this issue Dec 25, 2022 · 3 comments
Labels
Needs-Tag-Fix Doesn't match tag requirements Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting

Comments

@hsenag
Copy link

hsenag commented Dec 25, 2022

When I try to use the control sequence \EE ("Esc E") on a recent WSL,

ganesh@DESKTOP-VCELNMA:~$ echo -e 'foo\EEbar'
foobar

Whereas in native Linux terminals I've tried, and PuTTy, I get:

[ganesh@paxton:~]$ echo -e 'foo\EEbar'
foo
bar

This has recently become a problem for me because it's listed as the sequence for a newline (nel) for xterm-256color in recent versions of the ncurses terminfo database (follow the link to xterm-new and then xterm-p370). It's also documented as an Xterm control sequence here.

From browsing the changelog I think this was added in early 2021 and has recently made its way into Ubuntu - it's not there in Ubuntu 20.04 and is there in Ubuntu 22.04. One way to see if it's listed on a particular machine is to run infocmp -x -1 xterm-256color | grep nel.

It goes wrong for me in practice with tools that use the Haskell terminfo library, which has this code to look up how to produce a newline. If nel isn't listed, then the fallback option works fine, but if it is listed then it tries to use \EE as instructed. This means that tools like ghci (the Haskell REPL) do this:

ghci> 5+510

instead of the expected.

ghci> 5+5
10

It can be reproduced without running a Linux shell by this .cmd file (rename to remove the .txt after downloading). You can see other control sequences do work by changing the E on the final echo line, for example changing it to an M invokes ri (scroll backwards). Of course without the WSL angle there's no particular reason to expect a random xterm control sequence to work in console.

Apologies if I've got completely the wrong end of the stick here about the problem, I didn't know anything much about how terminals actually communicate until I started digging into this problem. Now that I understand the issue better there should be various workarounds available (like setting TERM to something different).

@ghost ghost added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Dec 25, 2022
@hsenag hsenag changed the title console doesn't respect xterm-256color "Esc E" control sequence for newline console doesn't support xterm-256color's "Esc E" for newline Dec 25, 2022
@237dmitry
Copy link

237dmitry commented Dec 25, 2022

In Powershell works

PS > "foo`eEbar"    # pwsh
foo
bar

PS > "foo$([char]27)Ebar"    # powershell
foo
bar

In Command Prompt works too ( where ^[ is keyboard keys Ctrl+[ ):

C:\> echo foo^[Ebar
foo
bar

@j4james
Copy link
Collaborator

j4james commented Dec 25, 2022

@hsenag We added support for NEL (ESC E) way back in 2020 (see PR #3271), but it's possible you have a version of Windows that doesn't include that patch - you didn't say what version you're using. The notes on PR #3271 say it was released in build 19603, so if you have a version earlier than that you'll need to upgrade. Alternatively you can use Windows Terminal, which will always get the most recent features and fixes, without having to upgrade the whole operating system.

@hsenag
Copy link
Author

hsenag commented Dec 25, 2022

Thanks! And sorry for forgetting about the version info. Having had this on an older install of Windows, I recently reproduced this on a fresh install with what I thought was all the updates, version 19045.2364, but I now notice my system has been failing to download an update and I hadn't realised. I'll sort that out and try again.

@hsenag hsenag closed this as completed Dec 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs-Tag-Fix Doesn't match tag requirements Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting
Projects
None yet
Development

No branches or pull requests

3 participants