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

Unclear how to determine installed version? #7587

New Issue
Closed
opened 2026-01-31 01:07:57 +00:00 by claunia · 9 comments
claunia commented 2026-01-31 01:07:57 +00:00
Owner
Copy Link

Originally created by @tiesmaster on GitHub (Apr 23, 2020).

Originally assigned to: @zadjii-msft on GitHub.

For me, it's unclear how to determine what my currently installed version of the Windows Terminal is. I tried the following things:

Check the command-line arguments: but it's not listed, and "probing" for --version gives an error that it's not an argument that's expected.

Check the Windows Store (I installed it through that), but I don't see a version anywhere. I don't really use the Windows Store, so maybe I overlooked it, but these are the places I checked:

  • the detailed listing
  • My Library > Installed: it states when modified, but not the version
  • My Library > Installed: same as above
  • My Library > Downloads: it states versions, but not the Windows Terminal is not listed under Recent Activity, but Available Updates, and that doesn't list a version (see Context below)

Looked for an issue about this in this repo, but couldn't find anything related: almost any issue has the word version in it, since it's asked when creating an issue 😅

Checked the issue templates, although there is listed how to find the version of Windows, not of the Windows Terminal

The properties pane on the wt.exe executables I could find, but they're completely empty, as the files are also 0 bytes. I checked these locations:

  • C:\Users\ties\AppData\Local\Microsoft\WindowsApps\wt.exe
  • C:\Users\ties\AppData\Local\Microsoft\WindowsApps\Microsoft.WindowsTerminal_8wekyb3d8bbwe

Context

I was looking into an issue I keep running into (#3609), and noticed I was running an older version of the Windows Terminal. Before I was going to update it, I wanted to known which version I have installed, so I can cross check all the related issues, and comments, if I can expect it to be fixed.

Suggested Improvements

  • Add to the issue templates
  • Add to the main docs somewhere
  • Add support for --version argument to wt.exe
Originally created by @tiesmaster on GitHub (Apr 23, 2020). Originally assigned to: @zadjii-msft on GitHub. For me, it's unclear how to determine what my currently installed version of the Windows Terminal is. I tried the following things: **Check the command-line arguments**: but it's not listed, and "probing" for `--version` gives an error that it's not an argument that's expected. **Check the Windows Store** (I installed it through that), but I don't see a version anywhere. I don't really use the Windows Store, so maybe I overlooked it, but these are the places I checked: * the detailed listing * My Library > Installed: it states when modified, but not the version * My Library > Installed: same as above * My Library > Downloads: it states versions, but not the Windows Terminal is not listed under Recent Activity, but Available Updates, and that doesn't list a version (see Context below) **Looked for an issue about this** in this repo, but couldn't find anything related: almost any issue has the word version in it, since it's asked when creating an issue 😅 **Checked the issue templates**, although there is listed how to find the version of Windows, not of the Windows Terminal **The properties pane on the `wt.exe` executables** I could find, but they're completely empty, as the files are also 0 bytes. I checked these locations: * `C:\Users\ties\AppData\Local\Microsoft\WindowsApps\wt.exe` * `C:\Users\ties\AppData\Local\Microsoft\WindowsApps\Microsoft.WindowsTerminal_8wekyb3d8bbwe` # Context I was looking into an issue I keep running into (#3609), and noticed I was running an older version of the Windows Terminal. Before I was going to update it, I wanted to known which version I have installed, so I can cross check all the related issues, and comments, if I can expect it to be fixed. # Suggested Improvements * Add to the issue templates * Add to the main docs somewhere * Add support for `--version` argument to `wt.exe`
claunia commented 2026-01-31 01:07:58 +00:00
Author
Owner
Copy Link

@WSLUser commented on GitHub (Apr 23, 2020):

Go to the About Page. If you don't have it then you're running an extremely early build of Windows Terminal and should update to the latest release. However I do agree we need to add --version to check via CLI (verified this still doesn't work on the latest .11 release)

@WSLUser commented on GitHub (Apr 23, 2020): Go to the About Page. If you don't have it then you're running an extremely early build of Windows Terminal and should update to the latest release. However I do agree we need to add `--version` to check via CLI (verified this still doesn't work on the latest .11 release)
claunia commented 2026-01-31 01:07:58 +00:00
Author
Owner
Copy Link

@tiesmaster commented on GitHub (Apr 23, 2020):

👍 I was looking for something like the about page, but couldn't find it, completely overlooked the drop-down arrow.

Cool that the --version is being picked up ;) Thnx for the comment in #4632.

@tiesmaster commented on GitHub (Apr 23, 2020): 👍 I was looking for something like the about page, but couldn't find it, completely overlooked the drop-down arrow. Cool that the `--version` is being picked up ;) Thnx for the comment in #4632.
claunia commented 2026-01-31 01:07:59 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Jun 18, 2020):

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

Handy links:

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

@dschulman-repay commented on GitHub (Dec 15, 2021):

As of 1.11.3471.0, this still doesn't work the way I'd hoped it would. While wt -v does produce the desired information (in a warning dialog for some reason), I wanted a way to get it programmatically à la python -V without having to resort to parsing it out of something like REG QUERY "HKCU\SOFTWARE\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppModel\SystemAppData\Microsoft.WindowsTerminal_8wekyb3d8bbwe\Schemas" /v PackageFullName or REG QUERY "HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\wt.exe" /ve or REG QUERY "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\wt.exe" /ve.

Is there a way to do this? If not, would it be possible to add a different command-line flag to the wt executable with this behavior?

If there are no plans to add such functionality, I could always put together a PowerShell function like

function Get-WindowsTerminalVersion {
    $WindowsTerminalVersionRegistryHive = Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\wt.exe"
    $pattern = "_(.*?)_"
    $script:WindowsTerminalVersion = [regex]::match($WindowsTerminalVersionRegistryHive.Path, $pattern).Groups[1].Value
}

but that's pretty ugly and I'd rather not use it.

@dschulman-repay commented on GitHub (Dec 15, 2021): As of 1.11.3471.0, this still doesn't work the way I'd hoped it would. While `wt -v` does produce the desired information (in a warning dialog for some reason), I wanted a way to get it programmatically à la `python -V` without having to resort to parsing it out of something like `REG QUERY "HKCU\SOFTWARE\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppModel\SystemAppData\Microsoft.WindowsTerminal_8wekyb3d8bbwe\Schemas" /v PackageFullName` or `REG QUERY "HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\wt.exe" /ve` or `REG QUERY "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\wt.exe" /ve`. Is there a way to do this? If not, would it be possible to add a different command-line flag to the `wt` executable with this behavior? If there are no plans to add such functionality, I could always put together a PowerShell function like ``` function Get-WindowsTerminalVersion { $WindowsTerminalVersionRegistryHive = Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\wt.exe" $pattern = "_(.*?)_" $script:WindowsTerminalVersion = [regex]::match($WindowsTerminalVersionRegistryHive.Path, $pattern).Groups[1].Value } ``` but that's pretty ugly and I'd rather not use it.
claunia commented 2026-01-31 01:07:59 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Dec 15, 2021):

I'd hoped it would

Hey @dschulman-repay! I'm not sure your use case was captured in this issue (it looks like the original reporter wanted to see if they had a fixed vs. broken version of Terminal), so I'm not too surprised that this resolution didn't help you out. We're looking at offering this info in the environment in #1040; however, if that's not enough, I'd love to hear about your scenario!

In general, we encourage folks not to detect the Terminal version and make any application decisions based on it, because many of the underlying components that make up the Terminal are also part of the Windows Console. Behavioral decisions made based on the Terminal version will exclude folks who are using a new-enough console outside of Terminal, or using Visual Studio Code or the Visual Studio IDE's integrated terminal or even ConEmu on newer versions of Windows.

for some reason

It is a very sad reason ("displaying output in a dialog" section).

@DHowett commented on GitHub (Dec 15, 2021): > I'd hoped it would Hey @dschulman-repay! I'm not sure your use case was captured in this issue (it looks like the original reporter wanted to see if they had a fixed vs. broken version of Terminal), so I'm not too surprised that this resolution didn't help you out. We're looking at offering this info in the environment in #1040; however, if that's not enough, I'd love to hear about your scenario! In general, we encourage folks _not_ to detect the Terminal version and make any application decisions based on it, because many of the underlying components that make up the Terminal are also part of the Windows Console. Behavioral decisions made based on the Terminal version will exclude folks who are using a new-enough console outside of Terminal, or using Visual Studio Code or the Visual Studio IDE's integrated terminal or even ConEmu on newer versions of Windows. > for some reason It is a [very sad reason](https://github.com/microsoft/terminal/issues/4570#issuecomment-586551445) ("displaying output in a dialog" section).
claunia commented 2026-01-31 01:07:59 +00:00
Author
Owner
Copy Link

@dschulman-repay commented on GitHub (Dec 15, 2021):

While I can understand the rationale for not encouraging users to use the version of Terminal as a basis for application decisions, my use case is literally an inventory script of the sort that an admin might run remotely to see who's got what (and possibly push new versions of dangerously out-of-date applications as needed). At the moment, what I'm collecting looks like this:

Hardware
        Machine                                 Dell Inc. Precision 5550 (<machine ID>)
        CPU                                     Intel® Core™ i7-10875H CPU @ 2.30 GHz
        TPM                                     Enabled, Activated, Ready, Version 2.0
        Temperature                             60.1 °C / 140.2 °F (critical temperature 100.1 °C / 212.2 °F)
        BIOS version                            1.10.0 (2021-09-27)
        Product                                 0GX59H
        Baseboard                               /GGGL6D3/CNCMK0014I0544/
        Dell Service Tag                        GGGL6D3
        Express Service Code                    35870638571
        RAM                                     32 GB
        Video resolution and color depth        1920 × 1200 × 32
Battery
        Chemistry                               Unknown
        Capacity                                84290 mAh
        Status                                  On AC power
        Operational Status                      OK
        Manufactured                            2021-03-25
        Availability                            unknown
        Remaining charge                        100%
Disks
        Drive   Volume          Filesystem      Free space

        C:      OS              NTFS            263.60 GB free / 474.86 GB:     55.51%
Windows
        64-bit Windows 10 Enterprise version    2009
        OS build                                19043.1348 (Windows version 21H1, May 2021 Update)
        Windows product key                     D11RC-NTROL-VUSAW-BBUI6-NRT0E
        Installed .NET Framework version        4.8 (Windows 10 May 2020 Update)
        Installed .NET SDK version              6.0.101
        Installed .NET runtime version          6.0.1
        Windows Terminal                        1.11.3471.0
        PowerShell                              Core 7.2.1
        WSL
                 Ubuntu-20.04 (Running)         WSL 2 DEFAULT
                 docker-desktop-data (Running)  WSL 2
                 docker-desktop (Running)       WSL 2
Package management
        Chocolatey                              0.11.3
        WinGet                                  1.1.13405
OpenSSL                                         3.0.1
cURL                                            7.80.0
Visual Studio Code                              1.63.1
Python
        Installed version:                      3.10.1
Java
        OpenJDK 17.0.1                          17.0.1.0
        Java™ SE 8                              8.0.3110.11
        OpenJDK 17.0.1                          17.0.1.0
Network
        Domain (primary DNS suffix)             WORKGROUP
        Network adapter                         Ethernet 3
        Network type                            Realtek USB GbE Family Controller #3
        Link speed                              1 Gbps
        Connected to Internet?                  True
        VPN status                              Connected on Local Area Connection
        Ping round-trip time                    17 ms
        Estimated connection speed              58.63 Mbps
        Network SSID                            Network Local Area Connection 2
        Connection-specific DNS suffix          nc.rr.com
        IPv4 address                            192.168.1.105
        IPv6 address                            fe80::2cab:2a1f:39a1:a5eb%19
        Physical address                        48:51:C5:07:9D:EB
Admin
        Registered to                           Admin (Me Want Cookie)
        Userid                                  devnull (Me)
        System installed                        2021-05-16 12:05:27 EDT-04:00
        Last system boot                        2021-12-15 20:09:42 EST-05:00
        Current timestamp                       2021-12-16 14:31:04 EST-05:00
@dschulman-repay commented on GitHub (Dec 15, 2021): While I can understand the rationale for not encouraging users to use the version of Terminal as a basis for application decisions, my use case is literally an inventory script of the sort that an admin might run remotely to see who's got what (and possibly push new versions of dangerously out-of-date applications as needed). At the moment, what I'm collecting looks like this: ``` Hardware Machine Dell Inc. Precision 5550 (<machine ID>) CPU Intel® Core™ i7-10875H CPU @ 2.30 GHz TPM Enabled, Activated, Ready, Version 2.0 Temperature 60.1 °C / 140.2 °F (critical temperature 100.1 °C / 212.2 °F) BIOS version 1.10.0 (2021-09-27) Product 0GX59H Baseboard /GGGL6D3/CNCMK0014I0544/ Dell Service Tag GGGL6D3 Express Service Code 35870638571 RAM 32 GB Video resolution and color depth 1920 × 1200 × 32 Battery Chemistry Unknown Capacity 84290 mAh Status On AC power Operational Status OK Manufactured 2021-03-25 Availability unknown Remaining charge 100% Disks Drive Volume Filesystem Free space C: OS NTFS 263.60 GB free / 474.86 GB: 55.51% Windows 64-bit Windows 10 Enterprise version 2009 OS build 19043.1348 (Windows version 21H1, May 2021 Update) Windows product key D11RC-NTROL-VUSAW-BBUI6-NRT0E Installed .NET Framework version 4.8 (Windows 10 May 2020 Update) Installed .NET SDK version 6.0.101 Installed .NET runtime version 6.0.1 Windows Terminal 1.11.3471.0 PowerShell Core 7.2.1 WSL Ubuntu-20.04 (Running) WSL 2 DEFAULT docker-desktop-data (Running) WSL 2 docker-desktop (Running) WSL 2 Package management Chocolatey 0.11.3 WinGet 1.1.13405 OpenSSL 3.0.1 cURL 7.80.0 Visual Studio Code 1.63.1 Python Installed version: 3.10.1 Java OpenJDK 17.0.1 17.0.1.0 Java™ SE 8 8.0.3110.11 OpenJDK 17.0.1 17.0.1.0 Network Domain (primary DNS suffix) WORKGROUP Network adapter Ethernet 3 Network type Realtek USB GbE Family Controller #3 Link speed 1 Gbps Connected to Internet? True VPN status Connected on Local Area Connection Ping round-trip time 17 ms Estimated connection speed 58.63 Mbps Network SSID Network Local Area Connection 2 Connection-specific DNS suffix nc.rr.com IPv4 address 192.168.1.105 IPv6 address fe80::2cab:2a1f:39a1:a5eb%19 Physical address 48:51:C5:07:9D:EB Admin Registered to Admin (Me Want Cookie) Userid devnull (Me) System installed 2021-05-16 12:05:27 EDT-04:00 Last system boot 2021-12-15 20:09:42 EST-05:00 Current timestamp 2021-12-16 14:31:04 EST-05:00 ```
claunia commented 2026-01-31 01:07:59 +00:00
Author
Owner
Copy Link

@WSLUser commented on GitHub (Dec 15, 2021):

I noticed package management in your script. This is the route for your use case. There are many ways to determine a release is out for both Chocolately and eventually WinGet once they support updates. One method could be by git commit. You know what it is for each release, so it's reliable (unless Github is down).

@WSLUser commented on GitHub (Dec 15, 2021): I noticed package management in your script. This is the route for your use case. There are many ways to determine a release is out for both Chocolately and eventually WinGet once they support updates. One method could be by git commit. You know what it is for each release, so it's reliable (unless Github is down).
claunia commented 2026-01-31 01:07:59 +00:00
Author
Owner
Copy Link

@dschulman-repay commented on GitHub (Dec 16, 2021):

A lot of the applications I'm tracking have no (public) Chocolatey packages and aren't set up for Windows Package Manager (nor are they registered with Ninite or Scoop), either. Is there no alternative but to set up private Github repos for all of them?

@dschulman-repay commented on GitHub (Dec 16, 2021): A lot of the applications I'm tracking have no (public) Chocolatey packages and aren't set up for Windows Package Manager (nor are they registered with Ninite or Scoop), either. Is there no alternative but to set up private Github repos for all of them?
claunia commented 2026-01-31 01:08:00 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jan 10, 2022):

Is there another process that's running at 100% CPU? if so, that sounds a bit like #11916.

Regardless, I'd probably open a new thread for that issue, since that seems totally unrelated to determining the installed Terminal version.

@zadjii-msft commented on GitHub (Jan 10, 2022): Is there another process that's running at 100% CPU? if so, that sounds a bit like #11916. Regardless, I'd probably open a new thread for that issue, since that seems totally unrelated to determining the installed Terminal version.
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-Commandline Issue-Task Product-Terminal 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#7587
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?