starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-03 21:25:34 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

No support for xterm Send Device Attributes (Secondary DA) control sequence #8060

New Issue
Closed
opened 2026-01-31 01:19:45 +00:00 by claunia · 7 comments
claunia commented 2026-01-31 01:19:45 +00:00
Owner
Copy Link

Originally created by @zrait on GitHub (May 11, 2020).

Environment

Windows build number: [Version 10.0.19041.208]
Windows Terminal version (if applicable): 0.11.1251.0

Steps to reproduce

echo -e '\e[>c'

Expected behavior

A secondary device attribute response providing information that better describes what capabilities Windows Terminal actually supports.

Excerpt from xterm ctl sequences:

CSI > Ps c
          Send Device Attributes (Secondary DA).
            Ps = 0  or omitted ⇒  request the terminal's identification
          code.  The response depends on the decTerminalID resource set-
          ting.  It should apply only to VT220 and up, but xterm extends
          this to VT100.
            ⇒  CSI  > Pp ; Pv ; Pc c
          where Pp denotes the terminal type
            Pp = 0  ⇒  "VT100".
            Pp = 1  ⇒  "VT220".
            Pp = 2  ⇒  "VT240" or "VT241".
            Pp = 1 8  ⇒  "VT330".
            Pp = 1 9  ⇒  "VT340".
            Pp = 2 4  ⇒  "VT320".
            Pp = 3 2  ⇒  "VT382".
            Pp = 4 1  ⇒  "VT420".
            Pp = 6 1  ⇒  "VT510".
            Pp = 6 4  ⇒  "VT520".
            Pp = 6 5  ⇒  "VT525".

          and Pv is the firmware version (for xterm, this was originally
          the XFree86 patch number, starting with 95).  In a DEC termi-
          nal, Pc indicates the ROM cartridge registration number and is
          always zero.

Actual behavior

No response to control sequence

Why this matters right now?

When Windows Terminal sets TERM to be xterm-256color, certain popular applications expect it to respond to xterm control sequences. I came across this issue (and suspect many others have as well, although it's surprising to me that I didn't see an existing issue for it) because Emacs was hanging for 2 seconds on load whenever being launched inside Windows Terminal due to code in xterm.el (see here) (part of its terminal-capability-determination startup code) that queries the capabilities of xterm using the Secondary Device Attribute control sequence. Other terminals that masquerade as xterm (such as iTerm2, OS X's Terminal, and gnome-terminal) respond to this query.

Originally created by @zrait on GitHub (May 11, 2020). # Environment Windows build number: [Version 10.0.19041.208] Windows Terminal version (if applicable): 0.11.1251.0 # Steps to reproduce `echo -e '\e[>c'` # Expected behavior A secondary device attribute response providing information that better describes what capabilities Windows Terminal actually supports. Excerpt from [xterm ctl sequences](https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h3-Functions-using-CSI-_-ordered-by-the-final-character_s_): ``` CSI > Ps c Send Device Attributes (Secondary DA). Ps = 0 or omitted ⇒ request the terminal's identification code. The response depends on the decTerminalID resource set- ting. It should apply only to VT220 and up, but xterm extends this to VT100. ⇒ CSI > Pp ; Pv ; Pc c where Pp denotes the terminal type Pp = 0 ⇒ "VT100". Pp = 1 ⇒ "VT220". Pp = 2 ⇒ "VT240" or "VT241". Pp = 1 8 ⇒ "VT330". Pp = 1 9 ⇒ "VT340". Pp = 2 4 ⇒ "VT320". Pp = 3 2 ⇒ "VT382". Pp = 4 1 ⇒ "VT420". Pp = 6 1 ⇒ "VT510". Pp = 6 4 ⇒ "VT520". Pp = 6 5 ⇒ "VT525". and Pv is the firmware version (for xterm, this was originally the XFree86 patch number, starting with 95). In a DEC termi- nal, Pc indicates the ROM cartridge registration number and is always zero. ``` # Actual behavior No response to control sequence # Why this matters right now? When Windows Terminal sets `TERM` to be `xterm-256color`, certain popular applications expect it to respond to xterm control sequences. I came across this issue (and suspect many others have as well, although it's surprising to me that I didn't see an existing issue for it) because Emacs was hanging for 2 seconds on load whenever being launched inside Windows Terminal due to code in `xterm.el` ([see here](https://github.com/emacs-mirror/emacs/blob/master/lisp/term/xterm.el#L704)) (part of its terminal-capability-determination startup code) that queries the capabilities of xterm using the Secondary Device Attribute control sequence. Other terminals that masquerade as xterm (such as iTerm2, OS X's Terminal, and gnome-terminal) respond to this query.
claunia commented 2026-01-31 01:19:46 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 11, 2020):

I'm pretty sure we are replying to this message...

e7a2732ffb/src/terminal/adapter/adaptDispatch.cpp (L711-L715)

Though, I just tried reading the input with a really simple script and couldn't get any input... Hmm...

@zadjii-msft commented on GitHub (May 11, 2020): I'm pretty sure we are replying to this message... https://github.com/microsoft/terminal/blob/e7a2732ffbcf21203f3ac9d2ccbd8b53c992e0e2/src/terminal/adapter/adaptDispatch.cpp#L711-L715 Though, I just tried reading the input with a really simple script and couldn't get any input... Hmm...
claunia commented 2026-01-31 01:19:47 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 11, 2020):

OH you know what, I see what's happening. We're replying to the Primary Attributes request, but not the other ones.

CSI Ps c  Send Device Attributes (Primary DA).
            Ps = 0  or omitted ⇒  request attributes from terminal.  The
          response depends on the decTerminalID resource setting.
CSI = Ps c
          Send Device Attributes (Tertiary DA).
            Ps = 0  ⇒  report Terminal Unit ID (default), VT400.  XTerm
          uses zeros for the site code and serial number in its DECRPTUI
          response.
CSI > Ps c
          Send Device Attributes (Secondary DA).
            Ps = 0  or omitted ⇒  request the terminal's identification
          code.  The response depends on the decTerminalID resource set-
          ting.  It should apply only to VT220 and up, but xterm extends
          this to VT100.
@zadjii-msft commented on GitHub (May 11, 2020): OH you know what, I see what's happening. We're replying to the Primary Attributes request, but not the other ones. ``` CSI Ps c Send Device Attributes (Primary DA). Ps = 0 or omitted ⇒ request attributes from terminal. The response depends on the decTerminalID resource setting. CSI = Ps c Send Device Attributes (Tertiary DA). Ps = 0 ⇒ report Terminal Unit ID (default), VT400. XTerm uses zeros for the site code and serial number in its DECRPTUI response. CSI > Ps c Send Device Attributes (Secondary DA). Ps = 0 or omitted ⇒ request the terminal's identification code. The response depends on the decTerminalID resource set- ting. It should apply only to VT220 and up, but xterm extends this to VT100. ```
claunia commented 2026-01-31 01:19:47 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (May 11, 2020):

These DA reports are on my TODO list, but I've been putting them off because it's difficult to decide what we classify as at this point. We implement sequences from a wide range of terminals, including the VT500 series, but we don't have nearly enough coverage to claim to be something like a VT500. I'm not even sure we could claim to be a VT220 yet. And since the DA2 report doesn't apply to a VT101 (which is what we're currently claiming to be), it didn't make sense to support it yet. That said, we could just go with the XTerm hack that uses 0 to indicate a VT100, and that should at least keep Emacs happy for now.

@j4james commented on GitHub (May 11, 2020): These `DA` reports are on my TODO list, but I've been putting them off because it's difficult to decide what we classify as at this point. We implement sequences from a wide range of terminals, including the VT500 series, but we don't have nearly enough coverage to claim to be something like a VT500. I'm not even sure we could claim to be a VT220 yet. And since the `DA2` report doesn't apply to a VT101 (which is what we're currently claiming to be), it didn't make sense to support it yet. That said, we could just go with the XTerm hack that uses 0 to indicate a VT100, and that should at least keep Emacs happy for now.
claunia commented 2026-01-31 01:19:47 +00:00
Author
Owner
Copy Link

@zrait commented on GitHub (May 18, 2020):

If you can't support the VT220 command set, I do think it makes sense to report 0 as the first digit as that does seem to be what OS X Terminal, iTerm, and gnome-terminal are doing.

@zrait commented on GitHub (May 18, 2020): If you can't support the VT220 command set, I do think it makes sense to report 0 as the first digit as that does seem to be what OS X Terminal, iTerm, and gnome-terminal are doing.
claunia commented 2026-01-31 01:19:47 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Jun 23, 2020):

I thought I'd do a quick PR for this now, and immediately got stuck on deciding what to use for the second parameter - what would originally have been the firmware version on a DEC terminal. Some terminal emulators use that parameter to encode their version number (e.g. VTE 0.52.2 will use 5202, and XTerm patch 354 will use 354). Others hardcode a specific XTerm patch number to try and trick applications like VIM into thinking they're XTerm, so they get features like mouse support.

If you want to see the convoluted logic that VIM uses to determine whether certain features can or can't be used, have a look at the code here. As an example of how weird this whole setup is, they have a specific check for PuTTY as reporting version 136, while PuTTY itself only chose 136 to trick VIM into thinking it was XTerm!

So the question is, what do we want to do here? I'd initially thought I could pull something from the conhost file version info. But the system conhost version is just the Window build number, which you may not want to reveal. And the OpenConsole version bundled with WT is something else entirely, which makes it feel kind of pointless. Do we just hardcode something simple like 10 (the DEC equivalent of 1.0)? Or try and pick a number that works well for VIM? I really don't know.

Bottom line is I think this needs input from the core contributors. If you let me know what you'd prefer to use for the version number, I'd be happy to put together the PR.

@j4james commented on GitHub (Jun 23, 2020): I thought I'd do a quick PR for this now, and immediately got stuck on deciding what to use for the second parameter - what would originally have been the firmware version on a DEC terminal. Some terminal emulators use that parameter to encode their version number (e.g. VTE 0.52.2 will use 5202, and XTerm patch 354 will use 354). Others hardcode a specific XTerm patch number to try and trick applications like VIM into thinking they're XTerm, so they get features like mouse support. If you want to see the convoluted logic that VIM uses to determine whether certain features can or can't be used, have a look at the code [here](https://github.com/vim/vim/blob/ef6746f637adbdb6860b4fa0266c43c49fa498bc/src/term.c#L4566-L4684). As an example of how weird this whole setup is, they have a specific check for PuTTY as reporting version 136, while PuTTY itself only chose 136 to trick VIM into thinking it was XTerm! So the question is, what do we want to do here? I'd initially thought I could pull something from the conhost file version info. But the system conhost version is just the Window build number, which you may not want to reveal. And the OpenConsole version bundled with WT is something else entirely, which makes it feel kind of pointless. Do we just hardcode something simple like 10 (the DEC equivalent of 1.0)? Or try and pick a number that works well for VIM? I really don't know. Bottom line is I think this needs input from the core contributors. If you let me know what you'd prefer to use for the version number, I'd be happy to put together the PR.
claunia commented 2026-01-31 01:19:47 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Jul 22, 2020):

:tada:This issue was addressed in #6850, which has now been successfully released as Windows Terminal Preview v1.2.2022.0.🎉

Handy links:

@ghost commented on GitHub (Jul 22, 2020): :tada:This issue was addressed in #6850, which has now been successfully released as `Windows Terminal Preview v1.2.2022.0`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v1.2.2022.0) * [Store Download](https://www.microsoft.com/store/apps/9n8g5rfz9xk3?cid=storebadge&ocid=badge)
claunia commented 2026-01-31 01:19:48 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Aug 21, 2020):

🎉 As of Windows Insider build 20197, this is also supported in the traditional console.

@DHowett commented on GitHub (Aug 21, 2020): 🎉 As of Windows Insider build 20197, this is also supported in the traditional console.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-VT Help Wanted Issue-Task Product-Conhost Resolution-Fix-Committed
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#8060
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?